3

I am working with a client who wants to install SSL security for a couple pages on his site. He uses GoDaddy's shared hosting, and the current site we're working on is on a subdomain of the primary hosting account:

Example:

(Primary) www.coolsite.com
    (New one) www.completelydifferent.com
    www.someothersubdomain.com
    www.anotherone.com

When he purchased the SSL certificate, he bought it for the primary domain (www.coolsite.com), even though the security is needed for the new domain (www.completelydifferent.com). This wasn't a huge issue, because I was able to add a Subject Alternative Name to the certificate to include the new domain. I checked both sites with an SSL checker, and they both seem to be working correctly.

However, I'm running into issues when I'm trying to use SSL. I have all references to the registration page being linked with an absolute URL (https://www.completelydifferent.com/register.php), but when I tested the link to verify the security, I got the following error:

This is probably not the site you are looking for!

You attempted to reach completelydifferent.com, but instead you actually reached a server
identifying itself as www.coolsite.com.

This may be caused by a misconfiguration on the server or by something more
serious. An attacker on your network could be trying to get you to visit a fake
(and potentially harmful) version of amazon.com. You should not proceed.

I'm not sure why I'm getting this error since I added the other Subject Alternative Name, so I don't know what to do to fix this. I do know, however, that users will likely be scared away from this scary looking red screen warning them of security leaks.

Is there a way to do it without requiring him to buy another SSL certificate?

EDIT: Here's a screenshot from the GoDaddy portal showing the SSL certificate. The two blurred URLs at the top are the primary domain, and the SAN at the bottom is the one where I want to use SSL.

enter image description here

|improve this question
  • Did the CA actually sign the request that included the SAN? What is their policy on SANs in general? If you run openssl x509 -in <cert file> -text, is the SAN listed correctly? – SmallClanger Jul 14 '12 at 7:18
  • Where/how do I run that script? I have attached a screenshot from the SSL portal of the certificate that I see. – Jon Jul 14 '12 at 7:58
  • 1
    I can't quite tell from the blurring, but it doesn't look like there's a www prefix in the SAN. The domain name must exactly match either the CN or one of the SANs. Does it validate if you access via completelydifferent.com ? (assuming the DNS for that points to the right place) – SmallClanger Jul 14 '12 at 11:41
  • YES. I think that must have been it. Thank you SO much. I'm waiting on the new certificate to be issued and installed, but I'm almost sure that that was the issue. You're a life saver. – Jon Jul 14 '12 at 14:27
  • 1
    Cool. If it works, let us know and I'll write that up into an answer. – SmallClanger Jul 14 '12 at 15:39
2

When adding Subject Alternative names to a certificate, the same rules as the Common Name apply. The full domain name being used must exactly one of them.

In your case, you're using the domain www.completelydifferent.com but the single SAN is only given as completelydifferent.com. This isn't close enough and will cause the browser warning you've seen. What confuses the matter is that the browser awrnings (I think this is the same for all browsers) will show the CN of the certificate in the warning and not the SANs, so it gives the impression that the SAN isn't being read correctly.

Also useful: openssl is a command-line interface the the openssl library functions, and can be used to verify the certificate: openssl x509 -in <cert file> -text will show you the full text of the certificate file. (Some certificates include this text in the file)

|improve this answer
  • 1
    Yes, it would've been much more helpful if it listed the SAN(s). Thanks for the help! – Jon Jul 16 '12 at 12:48
0

If you buy a UCC, there is a primary fqdn then 4 or much more fqdn.
However, the primary id always will be the primary fqdn. It's why it is intended only to UC.

|improve this answer

Your Answer

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

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