There are 100’s of virtual subdomains on the main domain. The subdomains are created on the fly with a custom 404 script. A wildcard SSL cert is installed which secures all subdomains. Surfers keep coming to the site with https://www.subdomain.domain.com – which causes a security warning. What’s the work around to authenticate the server to these surfers who insist on using www. which essentially creates two subdomains?
Details
The main domain on the server has 100’s of virtual subdomains that are created on the fly with apache rewrites and a custom 404 script. A wildcard cert (*.domain.com) covers all of the virtual subdomains with the expected encryption. Everything works wonderfully well when someone comes to the site with https://subdomain.domain.com But when a surfer comes to the site with the url https://www.subdomain.domain.com, the presence of the www. basically signifies a second subdomain of the first subdomain and breaks the SSL cert.
I believe the following two things govern the wildcard SSL cert: (please correct me if I’m wrong)
There can only be one wildcard character used in a wildcard cert
- i.e. there is no such thing as a double wildcard cert such as *.*.domain.com
The wildcard must be the left most character
- i.e. a pattern of www.*.domain.com is invalid
The fact of having 100’s of subdomains makes it impossible to create individual SSL certs for every domain – hence the use of the single wildcard cert to cover all of the domains.
A rewrite directive in the .htaccess file or in httd.conf is too late to clean up the transaction, as the warning that the site is non secure gets generated during the handshake before the directives are processed.
Let me say that this is not my server and it is not my design. I have been asked to fix it. I have full access to the server (root).
Does anyone have any suggestions on how this can be fixed?
Is it possible to add 100’s of openSSL certs to a server to cover every subdomain?
ANY help or light shed on this subject is greatly appreciated.
That is a good idea. But once a wildcard subdomain is propagated in the dns servers, any subdomain will resolve to the main domain IP Address with the subdomain(s) passed to the website server as part of the requested URL which in turn attempts a TLS handshake with all subdomains attached. The result is that it does indeed find the correct server, but the wildcard cert fails when multiple subdomains are used.
To illustrate here is series of dig commands for my site with various subdomains:
dig markcain.com +noall +answer
markcain.com. 7124 IN A 69.16.194.231
dig www.markcain.com +noall +answer
www.markcain.com. 7118 IN CNAME markcain.com.
markcain.com. 7118 IN A 69.16.194.231
dig fubar.markcain.com +noall +answer
fubar.markcain.com. 246 IN A 69.16.194.231
dig www.fubar.markcain.com +noall +answer
www.fubar.markcain.com. 251 IN A 69.16.194.231
Thank you for your time in helping me with this. I really appreciate it.
For comparison here is the dig command for my wife’s website which doesn’t have any subdomains active. Notice the status of NXDOMAIN comment in the second dig (i.e. Non Existent Domain)
dig ruthcain.com
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15917
ruthcain.com. 6515 IN A 69.16.194.231
dig fubar.ruthcain.com
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 18262
;fubar.ruthcain.com. IN A
I got the following information from Somone77 in Matrix #sysadmin:envs.net chat below:
I wish I knew enough to help you out here.
@Ulfnic I don’t think they’re going to get a clever solution, that said this reminds me of Cloudflare’s approach to this problem back in the day (before they had their own suboridnate CA)
There’s not a lot of documentation I can find on this because it wasn’t the most secure solution when dealing with multiple customers (and without PFS ciphers, a decently large security concern).
The way Cloudflare used to work is when a customer would onboard, Cloudflare would request a certificate with SANs of, say, example.com and *.example.com, but also other customer’s SANs. This same certificate would then be used for multiple customers).
So say you have 100 subdomains… www.subdomain[0…99].example.com
Then you split that up to say groups of 20, such that you request a certificate with Subject Alt Names for:
*.[0…19].example.com
[0…19].example.com
In one cert, so you’d have in total 40 SAN entries for this cert, then another cert for each following group.
This lessens the number of separate certificates you need because you can reuse them. Then you can use a load balancer (i.e. nginx) capable of handling this and generate configuration files to reverse proxy the traffic to the real backend server hosting the service for that subdomain.
Alternatively, if this is for a more enterprise hosting solution, I’d look into a subordinate CA from a publicly trusted CA and then programmatically generate the certificates when services are set up/onboarded.
I’m curious to see how they’re generating their configs for the new domains, because each config could also include a new cert stanza for the subdomain and the www sub-subdomain. If they’re using LetsEncrypt, there’s no reason this couldn’t be fully automated as part of that process.
The downside is that they may ‘eventually’ hit LetsEncrypt’s limit for the number of calls that can be made to the API, but probably not before they hit other limits.
Adding CNAMEs and such won’t help this situation. Browsers ‘correctly’ by default try www prefixes to domain names. If it were me, I’d have www go to a HTTP-only web listener on a different IP, where a redirect would send the traffic to the correct HTTPS hostname. This should prevent the need to have a cert on the www prefix. The user will likely never see the ‘insecure’ warning since it’s just a redirect to a secure site.
Thank you. I will try this – but I’m thinking that I’ll bump my head on the fact that the wildcard in the SSL Cert has to be the left-most character. Capturing www with a wildcard subdomain for the purposes of a redirect, would probably wind up looking like www.*.domain.com which breaks the rules for SSL authentication.
But I will give this a try. Thank you for the suggestion.
I stated HTTP, not HTTPS. This redirect would allow those clients that like to insert www onto the beginning to get somewhere, and be redirected to the proper place. Doesn’t NEED HTTPS for this to work, as currently, if a browser attempts to auto-prepend www, it will also try HTTP if HTTPS doesn’t have a listener.