Apparently the (cancelled) product I was referring to was called StartEncrypt and is not the same thing as StartAPI. See this article for more details. The rest of my reply still seems accurate. Also, if I’m reading this code correctly, StartAPI does support verification via HTTP, but I haven’t found a canonical source for that.
Yep - it does. I wrote a perl client for it here: https://github.com/CRCinAU/startapi
I my opinion LE does not support CT Certificate Transparency, doesn' it?
Pls refer to this thread.
That thread is talking about several different matters. Let's Encrypt has not yet integrated various ways for the server to provide CT information to the clients when they connect, but Let's Encrypt absolutely submits all certificates issued to public CT logs.
crt.sh | % (X1, old intermediate)
crt.sh | % (X2, never used)
crt.sh | % (X3, current intermediate)
crt.sh | % (X4, not yet used)
1 Like
To achieve full effectiveness CT logging has three elements. One is mostly in place today and will be enforced by Google Chrome a year from now. One is coming together but needs work (we have almost a year left to do that) and the last one is a bit less finished, but there is a plan for how it’ll work.
We don’t trust CAs to always notice or admit when they issue certificates they shouldn’t have so…
- Certificate Authorities must irrevocably log certificates (Let’s Encrypt does this)
But it’s no good just having them promise to do it, so…
2. To check they did it browsers must verify any certificates they see were logged using an “inclusion proof” aka SCT (Let’s Encrypt doesn’t make this at all easy today, so this part isn’t working for 99.9% of Let’s Encrypt subscribers today).
However of course the server and log could tell your client one thing, and the rest of the world another so…
3. Browsers / browser vendors / somebody must gossip about the inclusion proofs they’ve seen to determine if there’s any inconsistency and report it. (This work is out of scope for Let’s Encrypt)
1 Like
And that's a bad thing, how? You're supposed to run your own CA for systems only you will use. A third-party CA is always a huge trade-off because trust isn't possible otherwise. If you only have yourself to trust, running your own CA is the best thing that could happen.
Let me repeat: Using any third-party CA for your internal systems is nonsense and proves you don't understand trust.
Second argument is moot, because short lifetimes don't matter if you automate things, which is how LE is supposed to be used.
It might be relevant if you have devices that you can't easily modify to add trust to your internal CA, like some embedded systems.
I'd disagree with this. I have internal systems, of which I'm the only user, for which I've made a point of obtaining LE certs. Browsers are complaining more and more about self-signed certs, and it's just simpler to use a trusted cert. And I have managed to automate issuance of all those certs, even though a couple of them still need to be deployed manually.
1 Like
The idea is that you generate and install your enterprise trust certificate in your own certificate stores, and you sign all your internal certs with that one top cert (or even a chain of intermediates, up to you). Thus, you are your own CA, and your certs are no longer self-signed in that case. You can do this even on mobile, though it's much more annoying than if you actually have enterprise MDM software.
That said, if you can access LE from a device, using LE as a turnkey solution that installs and just works everywhere is very tempting. There's far less turnkey workflow support for free local PKI, it's mostly either expensive enterprise suites or fragile home-grown scripts.
The comments here about internal self signed CA’s really show the sheltered mindset of folks in this arena. The reality is, there’s a lot more out there than the narrow wedges that people keep obsessing over.
Regardless of that, if LE would allow the root domain validation to cover sub domains and leave everything else the same, then 90% of my issues would evaporate on the spot. It would also allow LE to be used in many more situations than are currently possible.
Nevertheless, comparing LE with another CA and saying LE should be (offering) the same as <other CA> isn’t quite the way to initiate changes IMHO.
Presenting your problem with the use case and asking for improvement for that use case would be the way to go, not referring to another CA and claim LE should do the same.
Yes, and it makes good sense. My own experience goes to the contrary, though. I work for the U.S. government. We do have our own internal CAs. We have our own Windows image that we install on all our computers. But even so, when I go to a U.S. government website on a U.S. government computer, I get certificate errors. The CA certs aren't in the Java trust store either, so I get errors when I try to run Java apps as well (which is unfortunately a fairly common requirement). If the U.S. government (surely one of the better-funded organizations on the planet) can't manage to make this run smoothly, I think my odds are considerably lower.
I find the assumption that the government must be the pinnacle of know-how a little bit ridiculous.
1 Like
It’s not so much that as an example of a large enterprise, with its own CAs, that doesn’t seem able to make this work. Hopefully other such enterprises do better in this regard.
The point is simple, an internal CA is not a substitute for a properly recognised certificate chain.
The notion of ‘trust’ around CA’s is laughable. Like it or not, from a pure security standpoint, the entire design of hundreds of trusted roots by default is broken. I doubt that a proper audit could even locate every signed & cross signed trusted root CA that will be trusted by default by just about any device on the planet.
What does come out of a properly recognised cert is that you don’t get errors and you have an encrypted path from host to client - which is always much better than plain text. There are other solutions to assist with fraudulent certs, but its not quite there yet.
That being said, I still believe that validating the root domain should allow certs to be issued to any subdomain required. As long as care is taken that a subdomain validation doesn’t validate the root.
This is true, but they're working on changing that.
I don’t understand, you say that having hundred of different CAs and sub-CAs is bad, but then say it’s preferable to use them to verify your internal servers instead of a single private CA you control and manage?
Easy - Internal CA’s error by default, ‘trusted’ CA’s work perfectly by default.
The problem is that people confuse trust with CA’s. Right now, the trust model is broken - so we can only go on error vs no error by default (ie not installing random root CAs). Trust with respect to CAs is a marketing term, not a technical / security one.
When I say “private CA”, I don’t mean a self signed certificate, I mean a proper CA where you install the chain onto the client machines.
Any certs you make that chain to the private CA will be trusted by default by any browser/machine with the private CA certificate installed into it (Which should be very easy on a managed network)
You make the assumption that you control all the clients. Think of BYOD environments, systems open to certain wifi networks, but not the internet etc… IoT is massively like this.
Again, I’ve pointed out many times in this thread, just because it doesn’t connect to the internet doesn’t mean you have control over every device.