For development purposes I created a self signed SSL certificate where CN = *.example.com.

After installing the certificate, when browsing to any sub domain https://sub.example.com I got the nice green lock indicating that everything is OK, but when browsing to https://example.com I still keep getting an error. The browser says: "Server's certificate does not match the URL"

How can I resolve this issue so I will have 1 certificate that is valid for both all sub-domains and the main domain.

  • Did you get this working?
    – Anagio
    Jul 26, 2012 at 11:23
  • Sorry, I wasn't able to create quickly a self signed certificate with "Subject Alternative Names" so I just made another one for "example.com".
    – fudge
    Jul 30, 2012 at 5:09
  • Are you sure that example.com is pointing to the correct server that has your certificate? If you are using Google's naked domain redirect for example, it will show the message you describe.
    – Evgeny
    Jul 30, 2012 at 22:04
  • Which tool do you use to generate your self-signed certificate?
    – Bruno
    Jul 30, 2012 at 23:29

2 Answers 2


The name verification is guided by RFC 2818 Section 3.1, more specifically on wildcards:

   Matching is performed using the matching rules specified by
   [RFC2459].  If more than one identity of a given type is present in
   the certificate (e.g., more than one dNSName name, a match in any one
   of the set is considered acceptable.) Names may contain the wildcard
   character * which is considered to match any single domain name
   component or component fragment. E.g., *.a.com matches foo.a.com but
   not bar.foo.a.com. f*.com matches foo.com but not bar.com.

Here the "domain name components" a separated by the dots, and do not include them.

This is also clarified in RFC 6125 (which also discourages the use of wildcard certificates, but that's a different problem).

Instead of putting your host name in the Common Name RDN of the Subject DN, you could have two Subject Alternative Name entries in the same certificate: one for *.example.com and one for example.com. The CN is only meant to be a fallback solution anyway:

   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.

Does it work on https://www.example.com? If so you may need to create another certificate for your main domain.

  • Adding a second certificate is a solution, but I want to use 1 certificate. Is this even possible?
    – fudge
    Jul 29, 2012 at 6:59
  • I'm not sure, I just emailed GoDaddy asking them. I also have to buy a wild card SSL soon and wondering if i'll need two or them now my self. Did you test it using www in your domain name which is technically a sub-domain? I know that regular SSL's from GoDaddy cover both your www and non-www versions of your domain name. I don't know if that's just a feature GoDaddy offers or part of SSL in general.
    – Anagio
    Jul 29, 2012 at 7:32
  • I think I am missing a field called "Subject Alternative Names". Trying to create a new certificate with this field, will let you know if it worked.
    – fudge
    Jul 29, 2012 at 7:49
  • Godaddy just replied "The Wild Card SSL will protect the the domain itself as well as all subdomains. It protects the whole domain name."
    – Anagio
    Jul 29, 2012 at 10:23
  • Were you able to secure your entire domain?
    – Anagio
    Jul 29, 2012 at 22:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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