Let's Encrypt, Dehydrated and https://host vs https://host.fqdn
March 15, 2023 3:19 PM Subscribe
Very arcane tech question. I run a (Linux, Apache2.4) webserver with multiple virtual hosts on www.example.com. When I'm on a workstation in my example.com domain, i would like to go to 'https://www/', 'https://wiki/' etc. but browsers all complain that https://www/ does not match the name on the Let's Encrypt cert and the usual warning warning danger will robinson. https: with FQDN works ok, for example https://www.example.com of course. All workarounds I know fail. How do I fix this?
Resolv.conf references 'example.com' as you would expect. Ping www or wiki or etc. works as you'd expect. 'http://www/', etc. works as you'd expect.
I'm using Dehydrated to manage/renew my Let's Encrypt certs. Let's Encrypt will not add alternate hostnames to its cert without an FQDN.
I've applied mod_rewrite to rewrite all https://hostname/ to hostname.example.com, but my browsers still complain that https://hostname/ is insecure before grudgingly allowing me to proceed to https://hostname.example.com.
I can make this work with a self-signed or private-CA cert but that defeats the point of Let's Encrypt. I doubt anyone would sell me a cert with non-FQDN alternate hosts on it.
I would like to just enter https://www/ or https://wiki/ or whatever and just get to a Let's Encrypt-blessed URL of the site without triggering any complaints from the browser. I just want this for hosts already in my example.com domain.
Am I expecting too much? If not, how to fix on server-side?
Resolv.conf references 'example.com' as you would expect. Ping www or wiki or etc. works as you'd expect. 'http://www/', etc. works as you'd expect.
I'm using Dehydrated to manage/renew my Let's Encrypt certs. Let's Encrypt will not add alternate hostnames to its cert without an FQDN.
I've applied mod_rewrite to rewrite all https://hostname/ to hostname.example.com, but my browsers still complain that https://hostname/ is insecure before grudgingly allowing me to proceed to https://hostname.example.com.
I can make this work with a self-signed or private-CA cert but that defeats the point of Let's Encrypt. I doubt anyone would sell me a cert with non-FQDN alternate hosts on it.
I would like to just enter https://www/ or https://wiki/ or whatever and just get to a Let's Encrypt-blessed URL of the site without triggering any complaints from the browser. I just want this for hosts already in my example.com domain.
Am I expecting too much? If not, how to fix on server-side?
Best answer: It just plain isn't possible for a legit certificate authority to issue a certificate for a bare hostname like "www" or "wiki" as those hostnames cannot be looked up via DNS on the actual internet and are not able to be authenticated. Extra hostnames can be added to a certificate via the Subject Alternative Name field but every one on the certificate has to meet the authentication requirements of the certificate authority.
I suggest serving those hosts via an Apache virtual host on http where their only job is to redirect to the FQDN on https.
posted by zsazsa at 4:10 PM on March 15, 2023 [5 favorites]
I suggest serving those hosts via an Apache virtual host on http where their only job is to redirect to the FQDN on https.
posted by zsazsa at 4:10 PM on March 15, 2023 [5 favorites]
Can you generate your own certs for the short hostages, and add them to the server and your local trusted store?
posted by Horselover Fat at 4:34 PM on March 15, 2023
posted by Horselover Fat at 4:34 PM on March 15, 2023
Response by poster: How about putting ServerAlias *.example.com in the ssl VirtualHost *:443 configuration? Any unintended consequences? (Just came across this a moment ago)
posted by Quesaak at 4:54 PM on March 15, 2023
posted by Quesaak at 4:54 PM on March 15, 2023
Best answer: Why not create a bookmark for each hostname, where the title of the bookmark is just the hostname itself and the URL is the FQDN?
posted by fedward at 5:22 PM on March 15, 2023
posted by fedward at 5:22 PM on March 15, 2023
Best answer: Thanks to your responses, i went back and rethought what I really wanted to do. The basic question is how to apply rewrite rules before you get to HTTPS/SSL. I believe you can do it by doing the rewrite on the http:// version and then redirecting to the https:// version. For my unique case, I need http:// separate and not redirecting, so I cannot use this solution. This Ask shows that my knowledge of how to run Apache clearly has some awkward holes in it. Thanks to all.
posted by Quesaak at 5:57 PM on March 15, 2023
posted by Quesaak at 5:57 PM on March 15, 2023
FWIW you could do name-based virtual hosts for your distinct services that have to run over HTTP on port 80, and reserve HTTP on the short names for redirects to https://FQDN. I run the controller for my WiFi with that kind of setup.
posted by fedward at 6:07 PM on March 15, 2023
posted by fedward at 6:07 PM on March 15, 2023
At my organization, I deploy web apps over SSL with the help of a wildcard certificate (*.foo.org works for those * I specify). I'm not familiar with the certificate organizations you're using, but perhaps if they offer wildcard certs, you may be able to use those for deployment of arbitrary subdomains (along with whatever rules are required for your web server of choice for virtual hosts; nginx, Apache, what have you).
posted by They sucked his brains out! at 12:11 AM on March 16, 2023
posted by They sucked his brains out! at 12:11 AM on March 16, 2023
This is not something you really configure on your servers. You already have a local resolv.conf to do what Apple calls “search domains”, and I vaguely recall Microsoft using the same terminology. Having a sub-domain search in DNS has to be on each client; by the time HTTPS requests make it to your server, it’s too late to re-negotiate or re-write the domain. The TLS handshake happens before any HTTP web server directives (see: SNI extension to TLS)
In your example, having client machines set up with a search domain of example.com, any requests for www will resolve www.example.com. But typically when this is done, it’s paired with an internal certificate authority that is also installed on client truststores along with the search domain, and sometimes even with client certificates for mutual TLS. You wouldn’t use a “public” CA like Let’s Encrypt for your Example Corp internal names, because the names are meant to be internal only.
Then, to avoid the certificate warnings, the servers will provide both the “public” www.example.com certificate and the “internal” www certificate. Internal clients may use the shorter subdomain, or the full domain. External clients will not have the internal CA in their truststore, and so should only use the full domain, even if they try to “fake” membership with search domains.
It’s also worth noting, doing this sort of thing opens up potential issues with name squatting for your internal clients, especially in this current Internet era of custom TLDs. It was much easier to avoid name clashes when only ccTLD and the “traditional” .com .net .org .edu .gov .mil TLDs existed. You may try setting up user.dev as an alias for user.dev.example.com for a bunch of development servers, then inadvertently block access to a legitimate user.dev domain. Or even worse, decommissioning an internal name that can now correctly resolve to a public domain owned by an adversary. Now you have a bunch of internal data potentially being shipped out if any clients missed the memo on the name being removed from service.
I would highly recommend avoiding anything like these “shortcut” names. It’s far too easy to have something go wrong and break things. Even other solutions mentioned above, like HTTP redirecting to HTTPS with the FQDN, have drawbacks, i.e. browser extensions like “HTTPS Everywhere”, POST requests not working through redirects, etc. Just use FQDN for everything, and avoid tricks with DNS.
posted by jraenar at 1:38 AM on March 19, 2023
In your example, having client machines set up with a search domain of example.com, any requests for www will resolve www.example.com. But typically when this is done, it’s paired with an internal certificate authority that is also installed on client truststores along with the search domain, and sometimes even with client certificates for mutual TLS. You wouldn’t use a “public” CA like Let’s Encrypt for your Example Corp internal names, because the names are meant to be internal only.
Then, to avoid the certificate warnings, the servers will provide both the “public” www.example.com certificate and the “internal” www certificate. Internal clients may use the shorter subdomain, or the full domain. External clients will not have the internal CA in their truststore, and so should only use the full domain, even if they try to “fake” membership with search domains.
It’s also worth noting, doing this sort of thing opens up potential issues with name squatting for your internal clients, especially in this current Internet era of custom TLDs. It was much easier to avoid name clashes when only ccTLD and the “traditional” .com .net .org .edu .gov .mil TLDs existed. You may try setting up user.dev as an alias for user.dev.example.com for a bunch of development servers, then inadvertently block access to a legitimate user.dev domain. Or even worse, decommissioning an internal name that can now correctly resolve to a public domain owned by an adversary. Now you have a bunch of internal data potentially being shipped out if any clients missed the memo on the name being removed from service.
I would highly recommend avoiding anything like these “shortcut” names. It’s far too easy to have something go wrong and break things. Even other solutions mentioned above, like HTTP redirecting to HTTPS with the FQDN, have drawbacks, i.e. browser extensions like “HTTPS Everywhere”, POST requests not working through redirects, etc. Just use FQDN for everything, and avoid tricks with DNS.
posted by jraenar at 1:38 AM on March 19, 2023
This thread is closed to new comments.
posted by inkyz at 3:58 PM on March 15, 2023 [1 favorite]