I was just wondering if a wildcard SSL certificate necessarily needs to have a common name that contains the domain name of the sites that need the SSL certificate applied to.

For example, for the following:

Domain name: testdomain.com


  • www.testdomain.com
  • mobile.testdomain.com
  • mytestenvironment.testdomain.com

Do I necessarily need my wildcard certificate to have a common name of *.testdomain.com?

migrated from stackoverflow.com Sep 6 '12 at 5:59

This question came from our site for professional and enthusiast programmers.

  • serverfault.com might be a better place for this question. – Jay Riggs Oct 14 '09 at 0:23

Yes, your common name should be *.yourdomain.com for a wildcard certificate.

Basically, the Common Name is what states what domain your certificate is good for, so it has to specify the actual domain.

Clarification: It shouldn't "contain" the domain name of the sites, it should be the domain of the sites. I'm guessing there is no difference in your question, I just wanted to clarify, in case there's a misconception of what the domain should be, or what the certificate will be used for.


Yes, Wildcard SSL Certificate is best solution as per your requirements. With Wildcard certificate you will be able to protect your visitor’s information. There is no matter, which page of your website is submitted. Wildcard certificate secures unlimited number of sub domains that share the same domain name.

Installing the same wildcard certificate across all sub-domains & servers transmits inbuilt risk: if one server or sub-domain is compromised, all sub-domains can be equally compromised. Make sure that your website is protected with multiple levels of protection from all external and internal pressure.


Actually, you should use dnsName entries in the subjectAltName section of the certificate to specify the FQDNs, not the CN part of the subject. Using the subject for this purpose has been deprecated since RFC 2818 has been published in 2000. Quoting section 3.1:

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.

The only case where the contents of the subject are relevant in the context of server certificate validation is if there is no dnsName included in the subjectAltName, a case which has been deprecated for the past 17 years at the time of writing.

Usage of wildcard certificates is deprecated, as shown by section 7.2 of RFC 6125:

This document states that the wildcard character '*' SHOULD NOT be included in presented identifiers but MAY be checked by application clients (mainly for the sake of backward compatibility with deployed infrastructure).

Using the same private key for several services is usually considered bad practice. Should one of the services be compromised, communications from other services will be at risk and you'll have to to replace the key (and certificate) for all services.

I suggest RFC 6125 as a good source of information on this matter.

  • "And so are wildcard certificates": could you please elaborate? dnsName can contain a wildcard domain. Also, what should be in subject in that case? – WoJ Apr 27 '17 at 19:47
  • Have a look at RFC 6125 sections 1.5 and 7.2. As long as the subjectAltName contains at least one dnsName, the contents of the subject are irrelevant in the context of certificate verification. – Erwan Legrand Apr 28 '17 at 9:41
  • @WoJ I have edited my answer. I hope this is all clearer now. – Erwan Legrand Apr 28 '17 at 9:58

Your Answer

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