Skip to main content


I am amazed that Let's Encrypt has been around for 10 years.

I have used it for many years, but certainly not 10.

I still want to find time to deploy my own CA, but for most external-facing things, I just use Let's Encrypt, and I'm very pleased to be able to do so.

in reply to Neil Brown

With DNS-based auth you can use it for internal hosts as well.
in reply to Neil Brown

I, too, use Let's Encrypt.

And some day, I'd like to get back all the time that I used to spend generating my own CA, before LE came on the scene.

in reply to Neil Brown

Don't know if they still have it, but years ago, cacert.org had some really good documentation on their website to create a mostly automagic CA certificate signing authority similar to theirs.
cacert.org
in reply to Amber

@puppygirlhornypost2 Ooh, interesting! I didn't have anything specific in mind as I haven't really got into the project yet!
in reply to Neil Brown

I'm amazed it's only been ten years. It feels a lot longer.
in reply to Neil Brown

wait, it has ONLY been 10 years? I feel like it has been around longer but I suppose that is correct. I love it and use it extensively.
in reply to Neil Brown

@Neil Brown I just wish there was was a way to do your own CA and limit it to a single domain... I'd love to just have https on the internal domain but not be opening a security risk of that CA being used against other sites.
in reply to Shiri Bailem

@shiri Interesting! Yes, that would be a further mitigation against loss of control of the private key, I guess?
in reply to Neil Brown

@Neil Brown precisely, it's one of many things I'd love to see implemented in current standards... a restricted ca that explicitly limits how it can be applied. (it's right up there with me thinking there should be a static encryption standard as a companion to https)
in reply to Shiri Bailem

The phrase you're looking for is "Name Constraints", aka RFC5280. Lets you limit the CA to a single domain and subdomains under it.
in reply to Neil Brown

@Neil Brown I constantly feel like LE was vandalism against the security of the internet. Just keeping the incredibly dangerous and bad CA system around on life support and removing all the energy that had been built by the Verisign hack to replace it.
in reply to silverwizard

@silverwizard within the framework of the current approach, LE turned money for old rope into an easy to deploy, automatable, free convenience, IMHO.

Would it be ideal to change the system? Yes!

in reply to Neil Brown

@Neil Brown Yeah, saved the dying system, but I just can't considered it good, and am constantly surprised others do. (I'm not trying to tell you to hate it, but ya know, strong opinions, internet)
in reply to silverwizard

@silverwizard @Neil Brown has anyone actually established a better system really?

Not going to argue that LE doesn't have it's problems, or even just the underlying SSL system in general.

LE thanks to ease and being free without much "competition" it has the crucial problem of hosting far too high a proportion of the the certs for the whole internet.

SSL in general has the problem of CAs getting hacked and issuing fraudulent certs.

Only improvement I can think of in that security at all is maybe double-certified certificates? (require you to go through two wholly separate providers with the same key to have a valid key and requiring both to sign for any updates to go through and maybe a certificate chain for whenever it changes hands)

Beyond that it's always a cludge, people aren't going to check them themselves, they're not going to manage certificates themselves... so you just have a preauthed group of keys installed in your system, trust them to be above board, and then trust the providers of those keys to be above board. Honestly shocked we haven't had more issues, but that's kinda how security goes.

in reply to silverwizard

@silverwizard @Neil Brown nah, just "DANE" is kinda also a word and most people are still using google to search so lord knows where they end up
in reply to Neil Brown

Having run an internal enterprise CA before (and having replaced an existing one!), I have no particular desire to run a CA again. 😉
in reply to Jima

@jima

Neil-scale and enterprise-scale are very different beasts :)

@Jima
in reply to Neil Brown

Yes, but some of the aspects of enterprise-scale CAs do make things easier. 😂
in reply to Neil Brown

there's nothing particularly technically complicated about deploying your own CA.

Here's mine: github.com/rlipscombe/elixir-c… (because OpenSSL has terrible UX).

The complicated bits are keeping the private keys safe, auto-renewal, deploying the root certs to your various devices, etc.

But if you want _other_ people to access your servers, you're pretty much restricted to Let's Encrypt (or spending money), because they're not gonna install random root certs.

in reply to Roger Lipscombe

@rogerlipscombe

there's nothing particularly technically complicated about deploying your own CA


No, indeed. I've done it before, and just need to find the time to set it up again, secure it, and perhaps automate distribution.

(Yes, only for me accessing my own stuff!)

in reply to Roger Lipscombe

@rogerlipscombe Sure, but if you ever issue someone else a certificate from such a CA you’ve done them a terrible disservice
in reply to Jim Flanagan

@rogerlipscombe The reason behind this outburst is that when you stand up CA, you do so with certain tacit assumptions about how the certificates will be used. These assumptions are brought to bear when you need to reason about the impact of changes to how the CA is operated

If certificates are outside your control, they are deployed with a different set of tacit assumptions. There’s nothing in an X.509 certificate that can effectively encode these assumptions

in reply to Jim Flanagan

@rogerlipscombe And so any change in the operation of the CA is likely to break things for the external issuees, if the calendar doesn’t get there first
in reply to Jim Flanagan

@rogerlipscombe A large part of the reason the CA/B Forum is cranking down the allowed validity period of publicly-issued certificates is that automation becomes necessary when the validity period becomes small enough, and then the assumptions about certificate use, CA operation, and lifecycle can be encoded in the automation
in reply to Jim Flanagan

@rogerlipscombe Even running a CA within a small organization for a specific purpose can run into these issues. Eventually someone proposes standing up a CA for another purpose, and an astute middle manager observes, “Oh, Cindy has already done all the work to stand up a CA. Just get your certs from there.”
in reply to Jim Flanagan

@jimfl
Oh, for sure. Hard agree with almost all of that.

But there are scenarios (such as I think Neil's talking about) where you control the CA and the clients, and you are small enough to retain effective control but also small enough that you don't want to deal with the extra complexity.

Of course, once you get to a certain size, you should absolutely use something better, whether it's Let's Encrypt, a paid-for CA or (internal service stuff) cert-manager.

This entry was edited (1 day ago)
in reply to Roger Lipscombe

@rogerlipscombe
> Hard agree with almost all of that.

This sounds like an opportunity for me to learn something

This entry was edited (1 day ago)
in reply to Jim Flanagan

@jimfl
Nothing specific, no. Just the lack of nuance. To be clear: in a lot of scenarios (particularly security) you don't *want* nuance; you want nailed-down rules.

So that's not a slight against anything you've said. Please don't take it as one.

But: for someone like Neil, who's (I assume) just tinkering, running his own CA is relatively immune from mission creep.

I run my own CA... in my *homelab*. In my dayjob, I'm not touching that stuff with a bargepole. I'll pay someone else.

in reply to Roger Lipscombe

@rogerlipscombe @jimfl

for someone like Neil, who's (I assume) just tinkering


Sort of - for some things, I use self-signed certs, so this would just be a step up from that.