Forum Discussion
jroller
Nimbostratus
NimbostratusWildcard 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
- 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 
hooleylistCirrostratus
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
jroller
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.
RogerPelt_13185Yes, 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.
- jessica_howe
There are other Certificate Authorities also now in the market who offers Wildcard SSL Certificates at budget-friendly prices with the same technical features and benefits where you can protect the root domain and all connected subdomains on multiple servers.
Here are the links for the certificates
https://cheapsslweb.com/positive-ssl-wildcard
https://cheapsslweb.com/sectigo-positive-ssl-wildcard
This will save you at least 80% on every purchase.
- Arie
Altostratus
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.
