Skip to main content

SSL Certificates without Non-FQDNs- Fully Qualified Domain Name

Over the years, publicly-trusted CAs have issued SSL certificates with domain names of different types. The most common is the Fully Qualified Domain Name (FQDN). This is a certificate that has been issued with a name registered with an entity that manages a top-level domain (TLD), for example server1.domain.com. The differentiating characteristic about an FQDN is that it is unique. There is one controller of domain.com and that controller determines who can have any name under that root, such as server1.domain.com.

Along the way, public CAs also issued certificates with non-FQDNs, such as:

Server host name only, for example: server1
Server name with non-managed TLD, for example: server1.domain.local
(In this example, local is not a TLD per ICANN.)
Reserved IP addresses
(In this case, the IP address cannot be registered, see IPv4 and IPv6.)
Many SSL certificates have been issued that contain non-unique domain identifiers. Correspondingly, there are many security risks where publicly-trusted certificates issued with a non-FQDN could be used to attack an enterprise using the same name for internal usages.

The CA/Browser Forum decided to mitigate the risk by deprecating the issuance of certificates with non-FQDNs. As defined in the Baseline Requirements, the publicly-trusted SSL CAs will stop issuing certificates with non-FQDNs by November 1, 2015, and all unexpired certificates with non-FQDNs will be revoked by October 1, 2016. The CAs must also provide a warning of the deprecated use of such certificate to the applicant before issuance.

This issue is particularly a problem with Microsoft Exchange users where non-FQDN names are used frequently. Paul Cunningham, a Microsoft Exchange Server MVP, wrote this article to help address the Exchange issue.

The problem also affects other deployments. To help, the CA/Browser Forum published Guidance on the Deprecation of Internal Server Names and Reserved IP Addresses to explain the issue and provide recommended solutions.

Please take a look at the publications and see if you have a problem with non-FQDNs.

Comments

Popular posts from this blog

IPv4 header to requests when a client is using IPv6

  What is Pseudo IPv4? As a stopgap to accelerate the adoption of IPv6, Cloudflare offers Pseudo IPv4 which supports IPv6 addresses in legacy applications expecting IPv4 addresses. The goal is to provide a nearly unique IPv4 address for each IPv6 address, using Class E IPv4 address space, which is designated as experimental and would not normally see traffic. To learn more see  here . Options Add header:  Add additional Cf-Pseudo-IPv4 header only Overwrite headers:  Overwrite the existing Cf-Connecting-IP and X-Forwarded-For headers with a pseudo IPv4 address Cloudflare

bot hit - server response time and overall page loadtime increase - aws, ec2, google analytic, cloudflare, ms sql cpu usage 100%

 Dear All, I've recently facing website page load time and server response time issue,  troubleshooting -  1. IIS log via - http log browser (tool to identify the bot hit) 2. disallow in robots.txt 3. article found and feature enabled in Cloudflare   Bot Fight Mode Challenge requests matching patterns of known bots before they can access your site. Requests matching Cloudflare-identified, non-legitimate automated traffic patterns will be challenged and/or blocked by Cloudflare. And, JavaScript Detections Use lightweight, invisible JavaScript detections to improve Bot Management products. 4. AWS EC2  Add new security group for Cloudflare ips list Ref:  https://dev.to/johnmccuk/automate-aws-security-group-with-cloudflare-ips-la6 And referred follow articles: https://www.imperva.com/products/advanced-bot-protection-management/ https://blog.apnic.net/2019/11/15/how-to-hide-aws-ec2-instances-from-network-scanning-bots-using-ipv6/ https://pawelurbanek.com/ec...

Amazon AWS - Cloudfront configuration

Amazon Cloudfront Dynamic Content Delivery HTTP GET and HEAD   requests are currently supported by Amazon CloudFront. Over time, we will add support for POST requests.   Our sample setup You can convert your existing blog or setup a new blog from scratch to use cloudfront. For demonstration purpose, I'm going to setup a new blog called www.contentdeliverynetworklog.com and serve the whole blog via cloudfront as follows: Blog domain name:   www.contentdeliverynetworklog.com   (CNAME to cloudfront) Blog origin domain name:   cp.contentdeliverynetworklog.com . To fetch web content from this origin web server. Static asset domain name:   s0.contentdeliverynetworklog.net   (CNAME to cloudfront). Static asset origin domain name:   origin.contentdeliverynetworklog.net . Custom origin IP address for both static/dynamic assets:   75.126.153.203 Caching ruleset for your dynamic and static assets: I am going to use a combination of Batca...