SSL SAN certificate fails in resolving alternative name

0
votes

I am currently trying to secure a Wildfly 10 application server to accept SSL only. The server is in my local network. The server is part of my private domain. I have issued an SSL SAN certificate from my CA and configured Wildfly to use the certificate. I installed my CA as trusted CA in my Firefox browser. When I request a page from the Wildfly via SSL with just its basename (hostname without domain), Firefox reports a secure connection. But when I try to request a page via a fully qualified domain name it reports an ambigious certificate. The certificate was created via a wizard from my CA, so misspelled content tags should be not an issue. I double checked the values.

I am using a SAN certifiate, so that both requests (wfly10-ssl, wfly10-ssl.mydomain.local) should be reported as secure connections. When I inspect the certificate it reports both names as valid.

Does anybody have an idea where I am going wrong?

private domain: mydomain.local
server name (plain): wfly10-ssl
server name (fqdn): wfly10-ssl.mydomain.local

Certificate content (partial):
Common Name / CN = wfly10-ssl.mydomain.local
Subject Alternative Name / SAN = DNS=wfly10-ssl

https://wfly10-ssl:8443/ -> SSL OK
https://wfly10-ssl.mydomain.local:8443/ -> SSL failure, certificate is valid only for: wfly10-ssl

Best regards, CB

1
sslcertificatessl-certificatewildflywildfly-10

1 Answers

2
votes

The CN is ignored when there is a SAN available. This is according to the specification RFC 6125:

A client MUST NOT seek a match for a reference identifier of CN-ID if the presented identifiers include a DNS-ID, SRV-ID, URI-ID, or any application-specific identifier types supported by the client.

See also this comment in the Firefox source code.