Technical Forum
Ask questions. Discover Answers.
cancel
Showing results for 
Search instead for 
Did you mean: 

Wildcard SSL doesn't handle root domain?

jroller
Nimbostratus
Nimbostratus
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
7 REPLIES 7

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

hooleylist
Cirrostratus
Cirrostratus
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
Nimbostratus
Nimbostratus

 

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_13185
Nimbostratus
Nimbostratus

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.

 

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. 

Yes, obtaining an SSL Certificate directly from Certificate Authorities (CAs) is always a costlier option, whereas you can get the same Wildcard SSL certificates from other authorized vendors in the market, such as Certera offers the same authentic Wildcard SSL Certificates at a much affordable price starting at just $19.99/year!

Arie
Altostratus
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.