Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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!

share|improve this question

2 Answers 2

up vote 5 down vote accepted

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.

share|improve this answer
    
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. –  Austin ''Danger'' Powers Mar 30 '13 at 0:17
    
I've imported the SSL cert and everything is working great. No browser warnings now. Cheers –  Austin ''Danger'' Powers Mar 30 '13 at 9:36

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".

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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