Ошибка в subject alternative name

For an Atlassian application to be able to successfully establish SSL connection with LDAP, the certificate for the directory must be trusted. Typically, this certificate is imported into the Java stores for trusted certificates, in a file called a keystore. The default keystore file is called cacerts and it lives in the jrelibsecurity sub-directory of your Java installation.

Errors

• The connection to the LDAP fails with the an error «handling exception: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No subject alternative DNS name matching DOMAIN.COM found.»

nested exception is javax.naming.CommunicationException: DOMAIN.COM:636 [Root exception is javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No subject alternative DNS name matching DOMAIN.COM found.]=

The LDAP server uses a different certificate compared to what is imported into the Java environment.

• Although this is rare, the LDAP server uses a different server certificate to communicate.

  • it is possible that the LDAP server, either has multiple server certificates

  • OR the certificate imported in Java, is no longer present on the LDAP server.

Cause 2

Follow referral is enabled.

By default, «Follow Referrals» is turned on. 

Certificate requirement

• Subject name of the certificate should match the host name of the Directory server mentioned in the User Directory configuration page.

• The certificate should contain the LDAP server name.

• The certificate should be imported into JAVA runtime environment. Below command can be used.

  • Please replace «server-certificate.crt» with actual certificate name.

    1 keytool -importcert -keystore .jrelibsecuritycacerts -file server-certificate.crt

• Jira will need to be restarted to identify the newly imported certificate.
  The article Configuring an SSL connection to Active Directory discusses the steps in detail.

Subject Name from the certificate

Hostname from the User Directory configuration

Solution 1

• To get certificate used by the LDAP server, enable to the following debug logging.

• Once the certificate used LDAP server is identified, import the certificate into the Java environment.

Enable Logging

• Add the following to setenv.sh in JVM_SUPPORT_RECOMMENDED_ARGS

  • «-Djavax.net.debug=all»

  • Restart Jira.

  • Check the catalina log file for SSL handshake information

Snippet from the logs

• With the above logging enabled, the catalina.out, would log the certificate being received for the connection.

1 2 3 4 5 6 7 8 9 10 11 12 chain [0] = [ [ Version: V3 Subject: CN=WinLDAPnew.new.dsidhpura.lab Signature Algorithm: SHA256withRSA, OID = 1.2.840.113549.1.1.11 Key: Sun RSA public key, 2048 bits public exponent: 65537 Validity: [From: Tue May 12 19:07:25 IST 2020, To: Wed May 12 19:07:25 IST 2021] Issuer: CN=new-WINLDAPNEW-CA, DC=new, DC=dsidhpura, DC=lab SerialNumber: [ 12000000 05123d75 38577613 fb000000 000005]

• Below is the certificate in the Java environment

1 2 3 4 5 6 7 Alias name: ldaps Creation date: 12 May, 2020 Entry type: trustedCertEntry Owner: Issuer: CN=new-WINLDAPNEW-CA, DC=new, DC=dsidhpura, DC=lab Serial number: 120000000454d67e7f8f53f1c1000000000004

• Notice the serial numbers are different between the certificate received for communication and certificate imported into Java.

  • LDAP server certificate SerialNumber: 1200000005123d7538577613fb000000000005

  • Java environment certificate Serial number: 120000000454d67e7f8f53f1c1000000000004

Solution 2

With follow referral enabled.

• The DNS name resolution for the domain name should resolve to LDAP server, for which certificate is imported in the Java environment.
  • Using the screenshots from this article, the Domain name would be new.dsidhpura.lab.
  • This DNS name should resolve the LDAP server for which the certificate is imported in the Java environment.

The newest version of Google Chrome 58 requires that certificates specify the hostname(s) to which they apply in the SubjectAltName field. The error, Security certificate does not specify subject alternative names trigger if the certificate does not have the correct SubjectAlternativeName extension.

As part of our Server Management Services, we assist our customers with several such errors.

Today, let us see an effective way to fix this error.

Subject Alternative Name

The Subject Alternative Name field helps to specify additional hostnames to be protected by a single SSL Certificate.

This extension was a part of the X509 certificate standard before 1999. However, it wasn’t in use until the launch of Microsoft Exchange Server 2007.

Now Subject Alternative Names are widely in use for environments or platforms that need to secure multiple sites across different domains/subdomains.

We can find Subject Alternative Names in the address bar. Click the padlock in the browser to examine the SSL Certificate. In the certificate details, we will find a Subject Alternative Name extension.

What to do with Subject Alternative Names?

• Secure Host Names on Different Base Domains in One SSL Certificate:

A Wildcard Certificate can protect all first-level subdomains on an entire domain. Whereas Subject Alternative Names can protect both www.example.com and www.example.net.

• Virtual Host Multiple SSL Sites on a Single IP Address:

Hosting multiple SSL-enabled sites on a single server typically requires a unique IP address per site. However, a Multi-Domain (SAN) Certificate with Subject Alternative Names solves this problem.

• Greatly Simplify Your Server’s SSL Configuration:

A Multi-Domain (SAN) Certificate saves us the hassle and time involved in configuring multiple IP addresses on the server, binding each IP address to a different certificate, and trying to piece it all together.

Solution for Security certificate does not specify subject alternative names

• In order to solve the SubjectAltNames issue, we edit the file:

C:wamp64binapacheapache2.4.27confopenssl.cnf

Under [ Req ] section
uncommented: req_extensions = v3_req

Under [ v3_req ] section
Added: extendedKeyUsage = serverAuth
Added: subjectAltName = @alt_names

Under [ v3_ca ] section
Added: subjectAltName = @alt_names

Added new section [ alt_names ] at the bottom of the file
[ alt_names ]
DNS.1 = %domain%

Then we reload the new certificate into the Trusted Root Certification Authorities Store.

• Supply an extra parameter to openssl when we create the cert,

-sha256 -extfile v3.ext

Here, v3.ext is a file with %%DOMAIN%% replaced with the same name we use as the Common Name.

Typically we will set the Common Name and %%DOMAIN%% to the domain we are trying to generate a cert for. So if it was www.example.com, then we have to use that for both.

v3.ext

authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = @alt_names

[alt_names]
DNS.1 = %%DOMAIN%%

• Regenerate the certificate to include a Subject Alternative Name.

To fix the error for Chrome users, we have to regenerate the certificate. To do that we can use the Certificates MMC when we have an internal Certification Authority (CA).

1. From the webserver, open MMC and add the Certificates snap-in, managing the Computer account.
2. Then expand Certificates (Local Computer) > Personal > (right-click) Certificates > All Tasks > Request New Certificate.
3. Then choose Active Directory Enrollment Policy to use the existing internal CA.
4. Select the Web Server certificate template and click the link below it to enter more information.
5. Add the Common Name for the Subject Name, and the DNS name for the Alternative Name.
6. Enter a Friendly Name on the General tab.
7. Optionally, make the private key exportable on the Private Key tab and click OK.
8. Then click Enroll to generate the new cert from the CA and install it on the webserver.
9. The certificate will be installed. Click Details to view the new certificate.
10. On the Details tab, we see the Subject Alternative Name is on the new cert.

Now we configure IIS to use the new certificate or reconfigure Exchange web services using the Enable-ExchangeCertificate cmdlet.

• Disable the checking of SubjectAlternativeName in Chrome.

This is a work-around that will not function beyond version 65 of Google Chrome. Our Support Techs recommend using this method as a temporary fix.

By adding the following setting, Chrome can force to allow certificates that are missing the SubjectAlternativeName extension:

Windows registry (REG_DWORD):
SoftwarePoliciesGoogleChromeEnableCommonNameFallbackForLocalAnchors

We can add a registry key to Windows by entering the following at the Command Prompt:

reg add HKLMSoftwarePoliciesGoogleChrome /v EnableCommonNameFallbackForLocalAnchors /t REG_DWORD /d 1

When we enable this setting, Google Chrome will use the Common Name of a server certificate to match a hostname if the certificate is missing a SubjectAlternativeName extension, as long as it successfully validates and chains to a locally-installed CA certificate.

[The error continues to prevail? We can help you]

Conclusion

To conclude, the error, Security certificate does not specify subject alternative names trigger if the certificate does not have the correct SubjectAlternativeName extension. Today we saw how our Support Techs fix this.

var google_conversion_label = «owonCMyG5nEQ0aD71QM»;