14

I have an SSL cert in which CN is "abc.xyz.com". But the url shared to 3rd party organization to access a web app on our server is: "def.stu.com/what-ever".

When this arrangement is working for some 3rd party organization since a long time, a new organisation trying to access the URL is getting SSL Exception. According to them, the URL must be in line with Common Name. Something like: abc.xyz.com/what-ever.

Question:

Is it really mandatory to have URL like this abc.xyz.com/what-ever? If yes, how are other integrator were able to call it successfully so far?

Note: Most of the search on internet agree to the point that URL should be based on Common Name. Then I also found that, we can have multiple domain name under one Common Name (Subject Alternative Name [SAN] concept). But no where I got a clear picture. Can I use any tool and check, if the cert is using SAN. I am from Dev team with limited knowledge on security. Will really appreciate a concrete ans to the mentioned behavior of SSL Cert or some pointer towards it.

Improve this question
2
  • I may have some insight why one integrator was able to call it successfully. DNS resolution is opaque to the browser - so, if you have an attribute (such as a SAN) in the certificate that needs to be matched in the address bar, you can use an alias: "abc.xyz.com CNAME def.stu.com". As far as the browser is concerned you are now visiting abc.xyz.com which matches the SAN on the certificate, all good, certificate verification successful. But the existing DNS host records for the destination server haven't needed to be changed. Your integrator might have defined such an alias in their DNS.
    – Bruno
    Commented Dec 20, 2017 at 3:04
  • To check if&what SAN is in your cert: (1) in any browser if you succeed in connecting to the server, click on the padlock and follow obvious links or prompts (varies by browser) to 'certificate details' (2) if you have or can get OpenSSL (on any system you use) use openssl x509 -text -in filename [-inform der] to display cert from a PEM or DER file or openssl s_client -connect host:port -servername host | openssl x509 -text to display from a running server (3) if you have or get Java, keytool -printcert {-file filename | -sslserver host[:port]} similarly
    – dave_thompson_085
    Commented Dec 20, 2017 at 4:06

3 Answers 3

Reset to default
16

Your web browser will require the host name in the URL to match what is in the certificate.

It should check first the alternate subject name list (if the extension is present) to see if any of the entries matche or, if there is no SAN extension, the subject's common name field.

Improve this answer
10
  • this is most definitive answer. Certain applications may apply their own requirements (like it was mentioned by @SteffenUllrich), it is not a rule in general (for example, a widespread Microsoft CryptoAPI library doesn't fall into these requirements). General rule says that if SAN extension is presented, it is evaluated, otherwise CN field is used to validate the subject.
    – Crypt32
    Commented Dec 19, 2017 at 16:34
  • 8
    @Crypt32: "General rule says..." - There is RFC 6125 which forbids checking the CN if SAN for DNS is present (but not if SAN for IP is present). But it also repeats that CN is deprecated which was already said in RFC 2818 17 years ago. And the CA-Browser Forum Baseline Requirements require at least one SAN to be present which in combination with above RFC essentially means that CN will never be checked for domain names.
    – Steffen Ullrich
    Commented Dec 19, 2017 at 17:55
  • @SteffenUllrich, RFC/CAB forume can forbid anything, but real life is where we are living. => RFC are not yet followed even by widespread products (most products violate these requirements). I'm familiar with theory and RFC, but have to deal with reality, where different rules are working. Reality says that apart from Chrome there are no much widespread tools that deprecate Subject field.
    – Crypt32
    Commented Dec 19, 2017 at 18:52
  • 1
    @Crypt32: CAB forum baseline requirements is the reality which all public CA which are included in the browsers must adhere too. And if you can just keep using CN despite Chrome's behavior then you have probably a different use case than most others.
    – Steffen Ullrich
    Commented Dec 19, 2017 at 19:15
  • 1
    If I interpret this answer correctly, a key word here is "IF". Meaning, the CN is effectively ignored if the SAN extension is used. This is counter-intuitive and a common trap - the most important fqdn for which you made the certificate won't "work" if you don't also include that name in the list of alternate names. Apparently those writing RFCs don't know what the word "alternate" means.
    – John Fantastico
    Commented Jul 28, 2020 at 13:35
16

The domain of the URL must match the subject of the certificate. In former times this could be either by setting the domain as CN of the certificate or by having the domain set as a subject alternative name. Support for CN was deprecated for a long time (at least 17 years, see RFC 2818) and Chrome browser will not even look at the CN anymore so today you need to have the domain of the URL as a subject alternative name. Note that there can be multiple subject alternative names and thus the certificate can be used for multiple domains.

Improve this answer
2

According to them, the URL must be in line with Common Name. Something like: abc.xyz.com/what-ever.

They are wrong. The distinguished name used in a SSL/TLS certificate is just a hostname. It never includes the path component of a URL -- a certificate which included that text in a CN would be invalid.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .