HTTPS-only mode (is briefly mentioned and I recommend to LWN readers)
HTTPS-only mode (is briefly mentioned and I recommend to LWN readers)
Posted Jun 12, 2024 12:23 UTC (Wed) by dskoll (subscriber, #1630)In reply to: HTTPS-only mode (is briefly mentioned and I recommend to LWN readers) by jch
Parent article: Firefox 127.0 released
Actually, no, the web site does not need unrestricted access to the Internet for a wildcard certificate. You need one machine that can run acme-dns to obtain the certificate. Once the certificate is obtained, it can be distributed to internal machines however you like.
In my case, I have a machine with access to the Internet that gets the certificate, and it then rsyncs it to all of the internal machines that require it.
Posted Jun 12, 2024 14:06 UTC (Wed)
by jch (guest, #51929)
[Link] (16 responses)
That's only true if your network administrator agrees to give out wildcard certificates. (Or if you have a dedicated domain just for yourself.)
But your point stands: workarounds do exist, and we do manage, at the end of the day, to have a proper certificate on every server. However, none of this hassle would be necessary if the browser vendors had implemented unauthentified TLS.
Posted Jun 12, 2024 22:30 UTC (Wed)
by dskoll (subscriber, #1630)
[Link] (15 responses)
Yeah, I mentioned wildcard certs right from the start because those are much easier to manage, as long as all your hosts are named something.yourdomain.example. And yes, it does require buy-in from the network admin, but I would expect that in a given organization, the network admin would not try to obstruct things that can help the organization. :)
Posted Jun 13, 2024 8:43 UTC (Thu)
by kleptog (subscriber, #1183)
[Link] (8 responses)
We have a portal where you can submit CSRs and some admin needs to approve it. It's kind of OK, but you really don't want too short expiry periods or you literally spend a significant chunk of your time renewing certificates. Many of the machines are not in DNS or publicly accessible so automation is tricky. Something like authentication via proving you have access to the old private key would work, but I can't see anything like that in ACME (probably for good reasons).
Posted Jun 13, 2024 13:28 UTC (Thu)
by dskoll (subscriber, #1630)
[Link] (7 responses)
No, each time the cert needs to be updated, the network admin would rsync the wildcard cert to specific servers via SSH. The network admin would have a private SSH key with enough permission to do this on the internal machines, and the network admin would only SSH the key to specific machines that have been vetted and whose SSH keys are known. The internal machines don't need to be externally resolvable, or even have Internet access at all. This is what I do for my machines.
You probably also want to use an internal domain such as *.intranet.realdomain.example or *.completely-different.example for internal machines rather than your real public-facing domain if you are worried about someone obtaining a copy of the certificate. That somewhat limits the damage they can do.
Posted Jun 13, 2024 17:58 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (6 responses)
A lot of services read the certificate once during startup, so you also need to restart them. Then you also have services that store the certificate in some kind of a database. And dockerized services that might need an image rebuild.
It's really not that easy. For my home network, I just bought a 5-year wildcard certificate for $100, so I don't need to worry about rekeying everything. But that's really not a lot of security.
I wish SSL were hierarchical, so that I could sign my own subcertificates for individual domain names. Sigh.
Posted Jun 13, 2024 18:14 UTC (Thu)
by farnz (subscriber, #17727)
[Link] (3 responses)
I'd love it to be possible for LetsEncrypt to sign my private CA for 30 days, conditional on my CA only issuing certificates for my domain names (as verified by LE), while allowing my CA to be valid for 20 years.
The idea is that anyone who trusts LE only trusts certs I've issued (or my CA) for 30 days after the LE signature, but if I can persuade you to import my private CA cert, you trust certificates I issue until their expiry date (or my CA's validity date, whichever comes first).
The other thing I'd like in X.509 is the ability to have multiple chains from a certificate to a CA; it'd be nice to be able to have a single certificate that was verified via the LE chain (for public visitors), and verified via my private CA (so that I trust it even when the LE signature has expired, making it easier to replace the LE chain every 30 days).
Posted Jun 13, 2024 19:47 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
You use your private infrastructure to sign certs, and specify the URI of your CA in: "Authority Information Access - CA Issuers - URI" extension field. Then this URL can return a certificate that is signed by the Let's Encrypt CA. You simply update this certificate once the signature expires. And your CA is in turn limited to your domain via the "Name Constraints" ( https://datatracker.ietf.org/doc/html/rfc5280#page-40 ) extension.
Now to bad news: name constraints fail open. This makes them a non-starter for any realistic applications. They must be redesigned to fail-closed, if a library doesn't understand them, the certificate validation should fail.
Posted Jun 13, 2024 22:19 UTC (Thu)
by intgr (subscriber, #39733)
[Link] (1 responses)
I believe this is not correct. Every extension (such as Name Constraints) in a cert has a boolean flag called "critical".
Non-critical extensions may be ignored by implementations if they are not recognized (fail open). But the presence of unrecognized critical extensions will make the cert immediately invalid (fail closed).
It's up to the parent CA to mark the constraints as critical.
Of course there may be implementations that interpret Name Constraints incorrectly but that's another matter.
Posted Jun 13, 2024 22:41 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Proper modern implementation of restrictions would need to include something that poisons certificate validation for incorrect implementations.
Posted Jun 15, 2024 2:20 UTC (Sat)
by dskoll (subscriber, #1630)
[Link]
A lot of services read the certificate once during startup, so you also need to restart them
Yup, that's also scripted. It's a bit of a pain to set up, but once it's set up, it just runs on its own. Basically, each machine has a script that knows how to reload relevant services if a certificate has been updated; the sync script runs that script iff the cert has actually been updated.
And dockerized services that might need an image rebuild.
"Doctor, it hurts when I do that!" "Then don't do that!"
Posted Jun 15, 2024 3:24 UTC (Sat)
by intelfx (subscriber, #130118)
[Link]
Huh?
Please don't tell me you're baking secrets into docker images?
Posted Jun 13, 2024 11:57 UTC (Thu)
by jch (guest, #51929)
[Link] (5 responses)
The network admins are quite friendly, but while they're quite willing to trust me with a certificate for seminar-reservations.amediumsizeuniversity.fr, they're not going to give me a certificate that would allow an attacker to impersonate www.amediumsizeuniversity.fr. Go figure. Perhaps they don't trust my sysadmin skills?
I've already said it, but I'll keep repeating myself until corbet himself steps down from his throne and tells me to shut up: the opposition of the browser developers to unauthentified TLS costs us countless hours of pointless hassle.
Posted Jun 13, 2024 12:36 UTC (Thu)
by mbunkus (subscriber, #87248)
[Link] (4 responses)
Posted Jun 13, 2024 16:10 UTC (Thu)
by mikebenden (guest, #74702)
[Link] (2 responses)
Yeah, but now you're just reinforcing jch's point: I have a box serving static content (file downloads, replacing ye olde ftp server) for public unauthenticated access.
I don't need, nor do I want, the hassle of having to ssl/https-ify this box just because browser developers decided, in their wisdom, that their users are too dumb to be trusted to access plain unauthenticated http web sites :)
This situation is getting hilariously stupid. If my browser starts dictaging policy to me, and I can't disable that "feature" (because in practice it's WAY too much hassle to patch out undesireable behavior from a browser), then it's free/open source in name only ("de jure", fine, OK, but no longer "de facto")...
That, in a nutshell, is why we need a third party browser, one that respects the idea that really Free software ought to side with its *user*, not enforce some overbearing idea of "developer knows best", through either closed source or through the sheer PITA that is rebuilding currently available open source with all this crap edited out...
Posted Jun 13, 2024 17:02 UTC (Thu)
by zdzichu (subscriber, #17118)
[Link] (1 responses)
Posted Jun 13, 2024 17:10 UTC (Thu)
by mikebenden (guest, #74702)
[Link]
So, is "adding unnecessary external dependencies" part of your "doing sysadmining right" philosophy? Good to know, that explains a few things I've been wondering about lately... :)
Posted Jun 14, 2024 9:40 UTC (Fri)
by jch (guest, #51929)
[Link]
Yes, as said before, workaround do exist. But that's not the point.
HTTPS-only mode (is briefly mentioned and I recommend to LWN readers)
HTTPS-only mode (is briefly mentioned and I recommend to LWN readers)
HTTPS-only mode (is briefly mentioned and I recommend to LWN readers)
HTTPS-only mode (is briefly mentioned and I recommend to LWN readers)
HTTPS-only mode (is briefly mentioned and I recommend to LWN readers)
HTTPS-only mode (is briefly mentioned and I recommend to LWN readers)
HTTPS-only mode (is briefly mentioned and I recommend to LWN readers)
HTTPS-only mode (is briefly mentioned and I recommend to LWN readers)
HTTPS-only mode (is briefly mentioned and I recommend to LWN readers)
HTTPS-only mode (is briefly mentioned and I recommend to LWN readers)
HTTPS-only mode (is briefly mentioned and I recommend to LWN readers)
HTTPS-only mode (is briefly mentioned and I recommend to LWN readers)
HTTPS-only mode (is briefly mentioned and I recommend to LWN readers)
HTTPS-only mode (is briefly mentioned and I recommend to LWN readers)
HTTPS-only mode (is briefly mentioned and I recommend to LWN readers)
HTTPS-only mode (is briefly mentioned and I recommend to LWN readers)
HTTPS-only mode (is briefly mentioned and I recommend to LWN readers)