12

We have a subdomain (https://portal.company.com) that is the alias for a different hostname (defined in a CNAME record).

This dynamic DNS hostname (https://portal.dlinkddns.com) resolves to the public (dynamic) IP address of our office. At the office, the router is configured to forward port 443 to a server running a (Spiceworks) web portal that the staff can access from home. Even if the office's public IP address changes, the subdomain will still direct staff to the web portal. Everything works great- apart from the (expected) SSL certificate error staff see when they first connect to the site.

I've just purchased an SSL certificate, and am now in the process of completing a certificate signing request on the server.

Which leads me to my question...

When completing the certificate signing request, for "Common Name (e.g. server FQDN or YOUR name)", what should I enter?

Should I enter the canonical name (https://portal.dlinkddns.com) or the alias (https://portal.company.com)? The FQDN of the server itself is "servername.companyname.local"- so I can't use that.

Any suggestions or ideas would be much appreciated!

2 Answers 2

13

You use the name the service is accessed as. So if your portal clients visit https://portal.dlinkddns.com, use portal.dlinkddns.com. And if they visit https://portal.company.com, use portal.company.com.

If your clients will access both, get a certificate with one of the names as DN and the other as subjectAltName, so it can be used for both.

If I'm reading correctly between the lines of your question, all that will be accessed in a browser is https://portal.company.com, so in your case: get a certificate for that name.

3
  • I used "portal.company.com" and everything looks good so far. The CSR process is complete and GoDaddy have issued me with my SSL certificate. I'll update with details after I've imported the certificate into Spiceworks. Mar 30, 2013 at 0:17
  • I've imported the SSL cert and everything is working great. No browser warnings now. Cheers Mar 30, 2013 at 9:36
  • This is incorrect in a sense that the SAN DNS should always contain FQDN and never the hostname on top of that, the CN is deprecated so all the hosts should be in SAN DNS for the server authentication certs.
    – nethero
    Feb 22, 2022 at 15:00
8

If you have the domain company.com (for example) and you want the certificate's Common Name to "just work", then consider using a wildcard-based Common Name like this: *.company.com

Then the SSL certificate should work for https://company.com and https://www.company.com and whatever subdomains you choose to use.

Note: I have used this only in self-signed certificates, created with the openssl command, but it might also work for "real" certificates; I don't see a reason why they wouldn't. (But I've heard that wildcard certificates might be more expensive than non-wildcard certificates, when purchased.)

It's a shame that the openssl command doesn't give this information as a hint, when it asks for the Common Name. When self-signing my SSL certificates for test servers, I routinely use a Common Name in the format "*.company.com".

You must log in to answer this question.

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