Forum Discussion

jroller's avatar
jroller
Icon for Nimbostratus rankNimbostratus
May 05, 2008

Wildcard SSL doesn't handle root domain?

My understanding of this may be lacking, but is there no way for a wilcard ssl certificate to handle the "root" domain?

 

 

Example: I have a wildcard cert for "*.foo.com". It handles SSL requests as expected for "www.foo.com", but browsers will throw an identify verification error if the request went directly to "foo.com". Both https://www.foo.com and https://foo.com resolve to the same IP address/F5 Pool. That pool is using the wildcard cert (and works correctly with https://www.foo.com).

 

 

Is this not a function of a wildcard SSL certificate?

 

 

 

Thanks
  • 58296's avatar
    58296
    Icon for Nimbostratus rankNimbostratus

    I always suggest to compare all available wildcard ssl certificates from different certificate authorities. This site give you all comparision along with cost. You must try this.

  • Arie's avatar
    Arie
    Icon for Altostratus rankAltostratus

    Technically, wildcard certs are issued based on the unknown children of a subdomain. Most wildcard certs are issued for 3-part domains (*.domain.com), but it's also very common to see them for 4-part domains (e.g. *.domain.co.uk).

     

    You could use SNI on the VIP and install both the 2-part and 3-part cert, but that's not supported on any version of IE on Windows XP. Your best bet is probably to set up a dummy VIP (port 443) for the 2-part domain name with the appropriate 2-part cert and then redirect all requests to the right 3-part domain.

     

  • Yes, I do agree with above discussion that wildcard ssl doesn't support root domain when you order for *.[rootdomain.com]

     

    But this is the great news for you all because when your order your wildcard ssl from RapidSSL or GeoTrust Certificate authority then you are able to secure your root domain plus all sub domain under your root domain.

     

    Here are the links where authority confirm this support

     

    http://www.geotrust.com/ssl/wildcard-ssl-certificates/

     

    Search for [Bonus: secure domain.com for free when you order *.domain.com] in this page

     

    http://www.clickssl.com/ssl-certificates/geotrust/truebusinessid-wildcard (Platinum Partner of GeoTrust)

     

    search for [*Bonus: When you are purchasing GeoTrust True BusinessID Wildcard for .yourdomain.com, then you will secure yourdomain.com at free of cost.]

     

    I hope this little help may save your big money.

     

  •  

    I thought as much. Just wanted to make sure there wasn't something simple I was missing. Ideally, one could add the www to the https request with the F5, but I understand that's a chicken before the egg problem. It should be OK anyway. I think the root problem is when people come to "foo.com" and then do something secure (login). So I made an iRule to add www to a "foo.com" request, and that should help 90%+ of the complaints (barring we don't get a new certificate). Thanks.
  • Colin is correct, that the BIG-IP isn't doing anything to affect the issue. By default, the wildcard cert is valid only for *.foo.com, not foo.com. However, there is a relatively new option for supporting both *.foo.com and foo.com. Try searching this forum or on a search engine for "Subject Alternate Names". We got a wildcard cert from godaddy for *.foo.com. It also has a SAN for foo.com. I think SANs usage and support is becoming more and more common.

     

     

    Aaron
  • Colin_Walker_12's avatar
    Colin_Walker_12
    Historic F5 Account
    This is normal for a wildcard cert configured the way you described. Since *.foo.com does not include foo.com without a prefix, you get the security warning. This has nothing to do with the F5 box, and everything to do with the way SSL certs work.

     

     

    Colin