There have definitely been many guides and I took a stab at this a few months ago https://github.com/leonletto/ca-for-labs. I tried to make it simple enough for anyone who is wanting to build an internal lab. Happy to receive any feedback or requests. No web interface yet. Thinking about building an interface that conforms to the ejbca api?
Running one’s own root Certificate Authority in 2023
141–150 of 164 posts
Re: Running one’s own root Certificate Authority in 2023
#142Earlier quoted context omitted.
I don’t necessarily disagree, but to point out: issuing an intermediate CA does change the authority model a bit, insofar as it turns a single trusted issuance into a windowed lease to perform arbitrary issuances. On a practical level, the latter is more logistically complex (and needs to be reconciled with other hard-fought battles, like CT). Given that it’s roughly the same as a wildcard certificate in terms of end…
Nobody has ever adequately explained how a wildcard cert presents a meaningfully different security profile than a name constrained CA. Wildcard certs used to identify a subdomain are not logged in CT and nobody is freaking out about it. And if your answer is "because nested subdomains" you should also explain the differential risk of nested subdomains compared to wildcard certs, not fully qualified certs. I don't se…
One accepts an arbitrary subdomain as a matter of verification policy, and the other has broader PKI implications: how should verifiers handle name constraints with multiple prospective paths? How should they handle CAs that issue longer-lives certificates than the CA/B guidelines permit? CAs that allow end-entity certs with known insecure algorithm choices, etc?
In short, allowing user-controlled name-constrained intermediate CAs opens up multiple cans of worms that the ecosystem is not currently prepared to handle. Presenting a compelling argument for these user-controlled CAs means explaining (and getting buy-in) for solutions to the above.
Re: Running one’s own root Certificate Authority in 2023
#143“Cultural” technical issues are so frustrating to me. A certificate is fundamentally just a type of credential, like a password, but for historical reasons they’re treated like getting citizenship papers. There’s always this ceremony even in scenarios where it makes zero sense — such as internal-use certificates used for a gRPC API server behind a load balancer. Why - for the love of God why - can’t I just obtain a c…
> Ceremony is required. Ceremony, as in “a well established, rigorously implemented, meticulously documented, and diligently audited process” is required to establish and maintain trust. A CA promises that folks showing up bearing their certificate _are who they say they are_ - this doesn’t mean it is perfect (there are plenty of cases where public CAs went wrong) and some random person can place their trust in that…
Trust can be established in many different ways. Through paperwork (literally the case for some public CAs!), via automation, or some other means.
The difficulty in running a CA at a very large scale (public or private) is that the root certificate revocation becomes prohibitively difficult. For this reason, its security is critical and much ceremony is warranted.
A CA doesn’t have to be a giant basket with millions of eggs in it. I have scenarios where I need a CA cert just so it can sign two (2) leaf certificates to make some load balancer happy, or to establish a site to site VPN or whatever. This is just "marking" the issued certs with a common attribute so that a load balancer can trust 'n' servers without having to have 'n' distinct certificates in its trust list.
That scenario does not need the same ceremony as DigiCert or the Microsoft kernel driver signing root certificate. It’s just a “shared secret” in a Cloudformation/Terraform/Bicep template.
If that CA gets compromised, I can just re-run the template to generate and deploy a new one! No ceremony. Just press play.
Not every gets married like Beyonce at an exotic island destination with 500 rich & famous guests. Some people just go down to the local marriage registrar office, get the paperwork done, and go home.
Re: Running one’s own root Certificate Authority in 2023
#144Earlier quoted context omitted.
Nobody has ever adequately explained how a wildcard cert presents a meaningfully different security profile than a name constrained CA. Wildcard certs used to identify a subdomain are not logged in CT and nobody is freaking out about it. And if your answer is "because nested subdomains" you should also explain the differential risk of nested subdomains compared to wildcard certs, not fully qualified certs. I don't se…
One accepts an arbitrary subdomain as a matter of verification policy, and the other has broader PKI implications: how should verifiers handle name constraints with multiple prospective paths? How should they handle CAs that issue longer-lives certificates than the CA/B guidelines permit? CAs that allow end-entity certs with known insecure algorithm choices, etc? In short, allowing user-controlled name-constrained in…
Thanks, I appreciate a response with some substance.
> name constraints with multiple prospective paths
Can you expand on this for me? Is this really a problem?
> longer-live[d] certificates than the CA/B guidelines permit
The iCA cert would only be valid for 90 days (or less, they could make it 30 or 15 days). Would a cert be valid if the iCA cert that issued it is expired?
> known insecure algorithm choices
Disallow bad algorithms by policy. Evidence of issuance using a bad algorithm gets the iCA revoked and the ACME account locked out. Many clients don't allow insecure algorithms by their own policy.
If you're securing your internal network with bad algos but it never touches the wider internet, does it make a sound? Would this be better or worse than installing self-signed root CAs everywhere?
Re: Running one’s own root Certificate Authority in 2023
#145I'm building an app whose GUI runs in the browser talking to a local http server. The app (if and when it is ready) would be distributed as a standalone executable. A bit like Atom/Electron I guess. What I haven't figured out yet is how the browser-GUI could talk to its local backend-server over https. Can an exe contain its own root-certificate-authority somehow in a way that the app-exe can work without having to u…
Why? What's the potential attack you're preventing by encrypting communication of two local processes? You'd have to install a shady custom CA system-wide on your users, for a green lock that's 100% placebo. Just run firefox/chrome in app mode and hide the URL bar.
That's a good point. Maybe it is not needed. I'm thinking maybe in the future there could be a use-case to allow also others to connect to the app running on my PC.
Basically it is a content-creation app. You use it to develop content you want to later publish and which you can develop and QA on your PC. But when used in an team-setting there might be a use-case for the QA-group to easily see the latest version of the content, even though they would not be allowed to edit it.
I'm also thinking maybe some organizations might have a rule that only https: can be used.
Re: Running one’s own root Certificate Authority in 2023
#146I'm building an app whose GUI runs in the browser talking to a local http server. The app (if and when it is ready) would be distributed as a standalone executable. A bit like Atom/Electron I guess. What I haven't figured out yet is how the browser-GUI could talk to its local backend-server over https. Can an exe contain its own root-certificate-authority somehow in a way that the app-exe can work without having to u…
Dear god why? People using ports (even on ::1) is super annoying when it collides with development. Hunting down the offender is not always straightforward and introduces a new failure mode for you (when I’m already using that port for something else). Also, it opens the door for literally any other software (or xss attacks) to connect and issue api calls you may not expect. Just create a native app. Use something li…
There's a set of ports allocated for http by the standards. The app will choose to use the first one available, starting with 80. If all such ports are in use then tell the user sorry all ports are already in use. Please stop some apps already running on your PC which may be using these ports.
Re: Running one’s own root Certificate Authority in 2023
#147Earlier quoted context omitted.
what's wrong with using a dynamically allocated port?
How do you have a dynamic port assignment and know how to connect to it without publishing it somewhere? As far as I know, that is impossible.
The app will open the browser on the URL it responds to, including the port it found to be available.
Re: Running one’s own root Certificate Authority in 2023
#148Is there an Open Source program I could just run on the command-line, to have my own Certificate Authority? Or just to create a certificate? Or do I need to know all the gory details myself?
mkcert if you need only on one system - usually for development. step-ca/step-cli if you need a CA at residential or office domain. XCA if you don't mind a GUI and know how to get the root CA certificate into the system/browser trust stores. links in this comment: https://news.ycombinator.com/item?id=37542794
Thanks for the links.
Let me re-phrase my question slightly:
Is there any npm-modules I can install (with npm) which would allow Node.js to automatically serve https?
Re: Running one’s own root Certificate Authority in 2023
#149I eventually need to publish an article about how to run an HSM backed root CA on the cheap with m of n auth. Using nitrokey and some glue scripts you can get the cost below $500. If anyone is interested, let me know.
an article like that would be great!
Re: Running one’s own root Certificate Authority in 2023
#150Earlier quoted context omitted.
> Ceremony is required. Ceremony, as in “a well established, rigorously implemented, meticulously documented, and diligently audited process” is required to establish and maintain trust. A CA promises that folks showing up bearing their certificate _are who they say they are_ - this doesn’t mean it is perfect (there are plenty of cases where public CAs went wrong) and some random person can place their trust in that…
Trust can be established in many different ways. Through paperwork (literally the case for some public CAs!), via automation, or some other means. The difficulty in running a CA at a very large scale (public or private) is that the root certificate revocation becomes prohibitively difficult. For this reason, its security is critical and much ceremony is warranted. A CA doesn’t have to be a giant basket with millions…
> The difficulty in running a CA at a very large scale (public or private) is that the root certificate revocation becomes prohibitively difficult. For this reason, its security is critical and much ceremony is warranted.
Unless the end-to-end, from the CA to the final certs, are managed by yourself or your immediate team, the scale would be irrelevant, and some ceremony would be required, as would be some processes that are internal to the team. My personal approach to avoid much of this is to use really short-lived certs to avoid the revocation theatre, but that doesn’t avoid the need to ensure that the CA is fundamentally secure.
> If that CA gets compromised, I can just re-run the template to generate and deploy a new one! No ceremony. Just press play.
Indeed! That, and re-distribute and implement trust for your CA Chain to all machines that need it. Your examples work fine (and I agree with) for small-scale use-cases, but if you run PKI for anything except yourself, you have to take care of the P for the KI.
Look, I am no fan of the rent-seeking bullshit the big public PKI vendors make us go through, and the incredibly high cost per certificate model. Charge me a reasonable fee for verification, and charge me a reasonable fee to set up my certificate vending endpoint, and be done. The same goes for internal use-cases. But the fact remains that verification and process are required. Fortunately, ACME for internal use and sane APIs and workflows such as Vault or smallstep provide make things very easy and cost effective. As for $400 per month for Azure certificates? Run your own instance, with your own (supposed) management processes, and see how it tallies up…