The below is a reproduction of a customer situation where they moved from a SAN certificate to a wildcard cert thinking that it would be “easy”. The certificate in question was issued from their internal Windows CA and was installed onto Exchange. No issues were noted until they tried to then bind the certificate to Exchange and users immediately started to get errors in their browser. In Chromium based Edge they saw NET::ERR_CERT_COMMON_NAME_INVALID
This would be displayed like so.
Clicking the Advanced button, would reveal a slightly more verbose message stating:
This server couldn't prove that it's mail.tailspintoys.ca; its security certificate does not specify Subject Alternative Names. This may be caused by a misconfiguration or an attacker intercepting your connection.
The Subject Alternate Name comment is something we will come back to later.
Note that IE on the left is just fine with the certificate. Edge Chromium on the right is not. Edge has the error as shown above.
Why is Edge treating the certificate differently than IE? Why did this happen with the wildcard certificate, and NOT with the previous SAN certificate that was issued from the same internal CA infrastructure.
Why does Edge not trust the certificate even though *.tailspintoy.ca is present in the certificate? Well, it’s not really present in the way that it should be. If we take a section from the error message from the client the detail is there "its security certificate does not specify Subject Alternative Names".
Let’s review that…
There are two places to list the name/names that the certificate should be bound to. One is well formatted and is well structured. The other is unstructured and somewhat ambiguous.
-
commonName - ambiguous
-
subjectAltName - structured
This issue is not new. It was expressed over 20 years ago and the industry slowly moved to implement RFC 2818. Note the word slowly in that last sentence. RFC 2818 describes two methods to match a domain name against a certificate - using the available names within the subjectAlternativeName extension, or, in the absence of a SAN extension, falling back to the commonName. The fallback to the commonName was deprecated in RFC 2818 (published in 2000), but support still remains in a number of TLS clients, often incorrectly.
Edge is built from the Chromium project, so we can also take a look at those documents.
Intent to Remove: Support for commonName matching in certificates
Feature: Support for commonName matching in Certificates (removed)
We need to take a look at the offending certificate and see what is missing. Typically this issue will not occur with wildcard certificates from 3rd party CA providers, and is more likely to crop up in test labs where you are using a Windows CA and want to add in a wildcard cert to "make things easy".
Problematic Wildcard Certificate
Let’s look at the wildcard certificate, to rule out if there are any glaring errors or issues. Some common issues that are always worth reviewing are:
-
Certificate has a private key
-
Valid From date
-
Valid To date
-
Typos in the entered names
-
Certificate does not chain to trusted root
-
Missing intermediate certificates
None of those were applicable here. An overview of the certificate is shown below.
The Subject field contains what was entered during the request process, and there are no mistakes in the names. The entered data is correct.
Since this was issued by a Windows CA, we can see the name of the template selected – “WebServer”.
There are no SAN entries listed here, this is a classic certificate issued by Windows. Only the Subject field contains the entity to which this certificate should be bound to – *.tailspintoys.ca. There are no other SAN entries in the certificate.
Since there are no SAN entries present, this is an issue as modern browsers expect to find them and will not honour the commonName. See the note above regarding RFC 2818.
In short those SAN entries *MUST* be present nowadays on a wildcard certificate.
Back The Bus Back Up
How did we get here? The regular Exchange PowerShell or UI process was used to request this certificate.
*.tailspintoys.ca
The Certificate Signing Request (CSR) was submitted to the CA for approval, and the certificate was downloaded, installed and completed with no issues.
No Additional Attributes were added to the request. We will revisit the Additional Attributes shortly as this is the crux of the issue.
For this issue it does not matter if the EAC or PowerShell was used to request the certificate. Even if the EAC was used, this is the PowerShell that would be executed in the background.
New-ExchangeCertificate -PrivateKeyExportable:$true -FriendlyName 'Tailspintoys Wildcard' -SubjectName 'C=CA,S="ON",L="Mississauga",O="Tailspintoys Canada",OU="HQ",CN=*.tailspintoys.ca' -RequestFile '\\exch-2019-1\c$\Certs\2021\Wildcard\Cert.req' -GenerateRequest:$true -Server 'cd09078f-2b38-459d-a867-02d7aa19f1e1' -KeySize '2048'
If using PowerShell directly, the command is materially the same. But has humans we are more likely to refer to servers as their name rather than GUID.
New-ExchangeCertificate -PrivateKeyExportable:$true -FriendlyName 'Tailspintoys Wildcard 2022' -SubjectName 'C=CA,S="ON",L="Mississauga",O="Tailspintoys Canada",OU="HQ",CN=*.tailspintoys.ca' -RequestFile '\exch-2019-1\c$\Certs\2022\Wildcard\cert.req’ -GenerateRequest:$true -Server 'Exch-2019-1' -KeySize '2048'
Adding SAN Entries to Wildcard Certificate
Please review the security note below *BEFORE* implementing any change to your CA to make this work.
We did say that the Additional Attributes would have to be revisited….
Either we have to specify the attributes in the request, the certificate template retrieves them as part of the enrollment, or we specify at the time of submission.
If we wanted to add SAN entries to the certificate at time of request submission using the request as created above, the below needs to be added to the Additional Attributes. The syntax is:
san:dns=corpdc1.fabrikam.com&dns=ldap.fabrikam.com
In the example below, this was added to the Additional Attribute field:
SAN:dns="*.tailspintoys.ca"&dns="tailspintoys.ca"
The signed response was then used to complete the certificate successfully. Note that the SAN entries are present in this certificate.
Edge trusts the certificate as it is now able to locate the SAN entries that it expects.
Security Note
If you add the Additional Attributes to a certificate request, they will NOT be added by default, This is a security consideration, and that option is disabled by default for your protection.
Please read: Securing PKI: Technical Controls for Securing PKI | Microsoft Docs
By default the EDITF_ATTRIBUTESUBJECALTNAME2 flag is not enabled. Note that you do NOT see it present on a default install.
certutil.exe –GetReg Policy\EditFlags
It is strongly recommended not to enable the EDITF_ATTRIBUTESUBJECALTNAME2 flag on an enterprise CA. If this is enabled, alternative names are allowed for any Certificate Template issued, regardless of how the subject of the certificate is determined according to the Certificate Template. Using this feature, a malicious user could easily generate a certificate with an alternative name that would allow them to impersonate another user. For example, depending on the issuance requirements, it may be possible for a malicious user to request a new certificate valid for smart card logon and request a SAN which contains the UPN of a different user. Since smart card logon uses UPN mapping by default to map a certificate to a user account, the certificate could be used to log on interactively as a different user, which could be a domain administrator or other VIP account. If this flag is enabled, the CA should be limited to require Certificate Manager approval or limit enrollment permissions to only trusted accounts.
If you do an search using my favourite search engine, you will quickly note that enabling this feature is a definite risk. It allows users to abuse the feature unless you add additional process controls. It is not to be enabled without fully understanding these issues. Security researchers, Red Teams and attackers will abuse it and use it as an attack vector.
If the only reason you are reading this is to get a wildcard certificate in production, then it would be better to re-do the request as a SAN certificate (not wildcard) and take the time to specify the names.
Alternatively, if you want to create a wildcard certificate that will be issued by a Windows CA create the request outside of Exchange so you can specify the required SAN entries.
The below is only included for reference and is NOT intended for generic production use. This is being executed in an isolated test lab which has zero net worth.
To allow Additional Attributes to be entered during the CA, the EDITF_ATTRIBUTESUBJECALTNAME2 flag needs to be enabled. Note that the command below is deliberately not spelt correctly so it increases the chance or reading the warning before just pasting the command to a production system. Hint remove the extra T.
certutil.exe –SetReg Policy\EditFlags +EDITF_ATTTRIBUTESUBJECALTNAME2
After running the command, note that EDITF_ATTRIBUTESUBJECALTNAME2 flag is now visible.
To apply the change, the Active Directory Certificate Services (CertSvc ) must be restarted. If you are still in the cmd prompt, then this will suffice:
net stop certsvc && net start certsvc
To disable EDITF_ATTRIBUTESUBJECTALTNAME2 run:
certutil.exe –SetReg Policy\EditFlags –EDITF_ATTRIBUTESUBJECTALTNAME2
Note that there is a minus "-" before the property to disable. The command to enable uses a plus "+ ".
Cheers,
Rhoderick
