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.
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
Post a Comment