While working on a scenario, I got the error message "Server's certificates doesn't match the url".

Is it necessary that the certificate given from the website must have its URL? Is it necessary that the certificate must have the complete name of the URL or will it also work if I use a part of URL?

  • You can get this error message if you (1) use an incorrect certificate or (2) browse to your test web server via IP (as certificates are pinned to hostnames)
    – BlueCacti
    Jul 1, 2015 at 14:14
  • Encryption is not useful unless you know only the intended recipient can decrypt the messages. Without the hostname you can't be sure who holds the private key to the public key in a cert so you could be encrypting your message and sending it directly to an antagonist. Jul 1, 2015 at 16:04
  • I guess, this should not be a constraint for a system to system SSL communication where the certificates are exchanged and installed before hand and attached to specific identities. Can someone confirm?
    – Raja
    Nov 22, 2017 at 9:30

4 Answers 4


First, it's not a URL, it's a host name or domain name. The host name is one part of the URL. http://security.stackexchange.com/questions/92838/is-it-neccessary-the-website-certificate-must-have-site-url is a URL, and the host name is security.stackexchange.com.

Next, yes, at least one host name in the certificate must match the exact host name used to access the site. You can get wildcard certificates, e.g. *.example.com, which would match <anything>.example.com (but not <anything>.<anything>.example.com or example.com).

  • stackoverflow.com has certificate issued to "*.stackexchange.com" . As you mentioned, here host name used to access site does not match the host name to whom certificate is issued to, right ? certainly I am missing something, can you plz help understand. thx!! Feb 27, 2019 at 0:57
  • @RahulAgarwal That certificate has a lot of Subject Alternative Names set as well, one of which is stackoverflow.com (and another is *.stackoverflow.com).
    – Mike Scott
    Feb 27, 2019 at 10:23

Yes the hostname on the cert must match the hostname portion of the url the cert is requested from. That is a requirement because there is an expectation that SSL not only secure the communication (encryption) but also ensure the user is connecting to the proper server (authentication). Without that requirement it would be trivial to spoof users with a MITM attack. User browses https://example.com, MITM hacker can't create a valid CA signed cert for example.com so he just uses any valid cert. User sees the url is https://example.com and it is SSL secured so he must be safe right? Nope he is connected to the hackers server. So the browser is going to warn the user. Hey you tried to go to https://example.com, the real example.com would have provided a cert for example.com but I got something different so very likely you are under attack right now.

WWW or not to WWW

One common scenario which leads to errors is requesting a cert with a hostname of www.* such as www.example.com. Everything is fine if the user tries to go to https://www.example.com, but if you decide you want to join the 21st century and handle traffic at https://example.com the user will get an error (you also can't redirect without a different error). User is trying to go to example.com but getting a cert for a different hostname (www.example.com).

Avoid getting a www.* only cert

It is (semi) standard practice for the CA to include www.* as an alt name for cert when the requested hostname is a root domain (no subdomain). A request for a cert with a hostname of example.com will work with both https://example.com and https://www.example.com but if a request for a cert for www.example.com will only work with https://www.example.com.

My cert has already been issued with a www.* hostname

You could get a second cert issued to handle the https://example.com traffic and use the existing www only cert for https://www.example.com but that is kinda pointless as the new cert can handle both hostnames. You may want to check if your CA will reissue a cert with the root hostname instead of www for free. I doubt they will but they might especially if it is a more expensive cert.

Well not always true

It looks like some CAs (see comments) will now do the opposite and for a cert requested on www.example.com will add example.com as an alt name. Nothing can be simple I guess. Check with your CA and the cert details. To avoid browser warnings the hostname of the url being used needs to be listed in the cert as either the hostname or the Subject Alternate Name.

  • 4
    "The www subdomain is treated as a special case." Source?
    – TRiG
    Jul 1, 2015 at 15:21
  • You definitely need a source for www being a special case. I've never heard this. Please quote the relevant part of the RFC. Jul 1, 2015 at 15:34
  • 1
    www can be included by issuers as an alt name on plain certificate. That isn't a 'special case' though it has to be issued like that.
    – Dev
    Jul 1, 2015 at 15:35
  • 1
    A perfect example being GitHub's certificate. It is issued for github.com but list www.github.com as an altname.
    – Dev
    Jul 1, 2015 at 15:39
  • I guess I should have been more clear. I have never known a CA to not issue www.* as an alt name. The end result is the same. If you get a example.com cert you are good for both example.com and www.example.com. If you get a cert for www.example.com it is only good for www.example.com so always get a cert for root hostname (unless you need a non www subdomain). Jul 1, 2015 at 15:46

I found the answer from (RFC2818) https://www.rfc-editor.org/rfc/rfc2818#section-3.1 According to rfc If a subjectAltName extension of type dNSName is present, that MUST be used as the identity. Otherwise, the (most specific) Common Name field in the Subject field of the certificate MUST be used. Although the use of the Common Name is existing practice, it is deprecated and Certification Authorities are encouraged to use the dNSName instead.

We can use Ip's also , and as @mike said it can be hostname with wildcard operator.


Mike Scott posted a great answer. But it might be worth noting why it matters. On a technical level your data will still be encrypted. However your users might be turned away because they can't trust the certificate as most browsers will warn them of the error and usually make them perform extra steps through warning messages. The messages are made to look scary on purpose in an attempt to even turn away non-technical users. In some cases a browser might never let them visit your site at all. Overall don't do it. Your production site should never cut corners when it comes security.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.