Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this community
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?
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).
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.
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).
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.
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.
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.
I found the answer from (RFC2818) http://tools.ietf.org/html/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.
