[HN Gopher] Running one's own root Certificate Authority in 2023
___________________________________________________________________
Running one's own root Certificate Authority in 2023
Author : jandeboevrie
Score : 65 points
Date : 2023-09-16 19:07 UTC (3 hours ago)
(HTM) web link (wejn.org)
(TXT) w3m dump (wejn.org)
| obnauticus wrote:
| I 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.
| processunknown wrote:
| Please do
| dmayle wrote:
| I've just started down that route. I've got the nitro key hsm2
| in the mail, have heard the advice on using two levels (first
| root in the Key, and intermediary on the Device for easier
| revoking). I mainly want to issue client certificates so that I
| can expose internal sites on the public Internet via proxy
| without having to require a VPN for all of my users, though I'm
| also interested in certificate based SSH
| n0n wrote:
| Yes, please! I would be interested. Currently i'm fiddling
| around with vault as an ICA, so this sounds like a good next
| step
| marginallen wrote:
| [dead]
| NegativeK wrote:
| I went with DNS based Let's Encrypt for internal certificates,
| since I'm okay leaking my internal DNS names.
|
| > An obvious downside of this is having to guard a bunch of
| secrets and the need to rotate the host certificates yearly -
| because Apple says so.
|
| The guarding secrets thing makes me too uncomfortable with
| managing my own CA. I'm sure it'd be fine, but since there are
| other equivalent and safer ways to do it.. Name constraints are a
| thing in the spec for restricting your CA to specific domains
| (which is amazing,) but browser/etc support was crappy when I
| looked at it and maybe getting better? I don't understand why
| name constraints aren't implemented everywhere. Unless an
| enterprise environment is doing TLS inspection, name constraints
| are a way saner implementation.
| aberoham wrote:
| Did you use elliptic curve instead of RSA?
| soraminazuki wrote:
| > Name constraints are a thing in the spec for restricting your
| CA to specific domains (which is amazing,) but browser/etc
| support was crappy
|
| It's well supported now. I use it and it works for OpenSSL,
| Firefox, and Safari.
|
| Personally, I don't think there's much to gain from using
| public PKI for internal infrastructure. I already manage
| secrets on my personal devices and this is no different. Also,
| being able to issue certs for .home.arpa domains is nice too.
| mirchiseth wrote:
| I used to have my own local root CA as well but now trying the
| Let's Encrypt with DNS-01. What is the easiest combination of
| software to try it? I have failed miserably trying Opnsense +
| ACME client plugin + Cloudflare DNS + HAProxy / NGinx. I would
| get 100% ssllabs certs but somehow the reverse proxy won't
| forward to internal services. Next I am gonna go caddyserver
| for reverse proxy as it has SSL with LE inbuilt. Let's see.
| wejn wrote:
| A friend of mine runs dns01 thusly:
| https://ipng.ch/s/articles/2023/03/24/lego-dns01.html
| petronio wrote:
| I've had a lot of success with https://github.com/dehydrated-
| io/dehydrated . It exposes the different parts of the process
| (deploy challenge to DNS, deploy cert to filesystem, etc) as
| hooks, so it's pretty easy to integrate with anything and
| however you want, if you don't mind writing a bit of bash.
| There's a few scripts out there that use Cloudflare that you
| can use as well.
| taskforcegemini wrote:
| do you use https/have a cert in your webserver as well, or
| just on the proxy?
| fiddlerwoaroof wrote:
| The one thing you can't do with Let's Encrypt is generate a
| certificate with a CN of localhost which, since browsers are
| getting really picky about mixed HTTP/HTTPS content, is a real
| issue with local development using certain web features.
| moondev wrote:
| You also can't generate a cert for a double wildcard, like
| mydomain . com . * . * Or an entire domain, although I'm
| unsure if that is possible with your own CA as well
| jeroenhd wrote:
| You can generate the certificate but browsers don't like
| multiple wildcards. Any application following the rules set
| out by RFC 6125 should reject multiple wildcards as far as
| I can tell.
|
| Some browsers (notably Firefox) used to support multiple
| wildcards, but then again it also trusted domain
| certificates signed by other domain certificates for years,
| so that's not much to go by. These days, I don't think a
| single browser will accept _._.foo.bar.
| sneak wrote:
| Why not register a domain, get a cert for it, and point it at
| 127.0.0.1? Then nothing can complain.
| fiddlerwoaroof wrote:
| The other advantage of running your own PKI is you can
| intercept and decrypt arbitrary traffic on the network.
| punkybr3wster wrote:
| I've also struggled with this. Is there an elegant solution
| that you're aware of? Everything I've tried feels really
| rickety.
| ceejayoz wrote:
| For localhost, there's not much downside to a self-signed
| cert.
| unethical_ban wrote:
| Browsers won't offer to save passwords on self signed
| sites.
| lozenge wrote:
| You might be able to get around this using the Chrome
| "flags" page, search for unsafely-treat-insecure-origin-
| as-secure.
| fiddlerwoaroof wrote:
| Chrome flags are pretty annoying to use, especially if
| you use the same browser for regular browsing.
| fiddlerwoaroof wrote:
| I've been using cfssl[1] to generate a root certificate + a
| localhost certificate and then trusting the root.
|
| [1]: https://github.com/cloudflare/cfssl
| xg15 wrote:
| > _is a real issue with local development using certain web
| features._
|
| Is it? I thought browsers treat localhost/127.0.0.*
| specifically as if it were served over https, even if it
| isn't - otherwise, you could basically forget developing
| anything locally.
|
| Is there any feature which doesn't treat localhost as a
| secure origin?
|
| I figure you can always buy a hostname, get a cert using the
| DNS-01 challenge, then resolve the domain to 127.0.0.1 though
| - or getting back to the OP and running a custom CA.
| fiddlerwoaroof wrote:
| I have a dashboard I run via nginx on localhost that makes
| a bunch of requests to various https endpoints. It
| definitely doesn't just work unless you have a trusted SSL
| certificate and run localhost as HTTPS
| xg15 wrote:
| Huh, that's odd. Gonna test this as well then.
| woodruffw wrote:
| > I don't understand why name constraints aren't implemented
| everywhere.
|
| They have weird semantics, especially in scenarios with
| multiple prospective validation paths: path `EE -> ICA' ->
| ICA'' -> TA` might result in different name constraints than
| `EE -> ICA' -> ICA''' -> TA`, resulting in hard-to-debug
| validation errors (or successes) depending on the user's trust
| store state.
|
| (I don't believe that's why Chrome doesn't support them,
| however. Chrome's stated reason[1] is that they don't support
| them on user roots because RFC 5280 doesn't require them to,
| which is IMO a correct reading of the spec.)
|
| [1]:
| https://bugs.chromium.org/p/chromium/issues/detail?id=107208...
| jiggawatts wrote:
| "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 cert like
| this _directly_ out of a secret store such as an Azure Key
| Vault!?
|
| These things are already full hardware security modules (HSMs)
| with all of the capabilities required to run just about anything
| short of a public Root CA and maybe even that too.
|
| But no.
|
| NO!
|
| Script it yourself. Make a root cert, "upload" it, make a cert,
| sign it, upload it, link it, renew it, re-configure it, and on
| and on. Oh... you wanted a CRL too? A 1kb file? Ha-ha! No. Make
| it and host it yourself!!
|
| It's absurd.
|
| So many services depend on a simple CA->cert setup: VPNs, API
| auth, load balancer back-ends, clusters, etc...
|
| But my mark my words: no cloud will have a trivial turnkey
| solution this decade.
|
| This is because running a CA is _culturally accepted to be a hard
| problem_. It is! If you're DigiCert. It isn't if you're building
| a three-server internal use cluster. But the problem is _hard_ ,
| you see? That accepted fact! Everyone knows it! _Ceremony is
| required_. We can't just _hand_ your sever a 1kb credential file!
| That would be... unconventional!
|
| It's just not the way things are done, so stop asking.
| stanleydrew wrote:
| This is a decent rant, and I mostly share your frustration.
|
| But At least GCP and AWS have certificate authority products
| which essentially do work the way you want them to:
|
| https://cloud.google.com/certificate-authority-service
| https://aws.amazon.com/private-ca/
|
| Azure may well have one too, I just don't use their service.
| andrewstuart2 wrote:
| I've done similar for something like 8 years with vault as my
| intermediate issuer, almost exclusively using cert-manager once
| that was mature enough, and my own little utility before that.
| It's so nice getting certs for side projects or self hosting in
| an instant and with an encrypted (pgp) offline (flash drive in a
| safe) CA I'm never really worried about having to reroll.
| Installing the CA is pretty trivial on most devices and means I
| don't have to worry about CTLs or rate limits, which is
| especially helpful when I'm hacking on a saas side project that
| ends up requesting 10+ certificates every test run.
| nemo wrote:
| This is not really an Apple thing, it's an industry trend (and a
| good one IMO). Apple's generally applying the same criteria
| Chrome is:
| https://chromium.googlesource.com/chromium/src/+/HEAD/net/do...
| xg15 wrote:
| Seems Chrome is specifically making an exception for custom
| root CAs though:
|
| > _This will only apply to TLS server certificates from CAs
| that are trusted in a default installation of Google Chrome,
| commonly known as "publicly trusted CAs", and will not apply to
| locally-operated CAs that have been manually configured._
| nemo wrote:
| [delayed]
| morpheuskafka wrote:
| Doesn't the first Apple link specifically say the 398-day limit
| doesn't apply to self-signed CAs?
|
| > This change will affect only TLS server certificates issued
| from the Root CAs preinstalled with iOS, iPadOS, macOS, watchOS,
| and tvOS.
|
| > This change will not affect certificates issued from user-added
| or administrator-added Root CAs.
|
| The second link about the other restrictions (including <=825
| days validity) does appear to apply to all CAs.
| wejn wrote:
| And yet, my homegrown root CA cert with 3650 days of validity
| hums along just fine...
|
| [edited: but since I also want to have host certs that are on
| various internal servers, the short validity applies to them]
| pxeboot wrote:
| I am not sure if the same rules apply to 802.1x authentication,
| but we use self signed certs with 2 year validity for EAP-TLS
| and have never had any issues on iOS devices
| c0l0 wrote:
| Actually running a CA, even if only for private purposes, without
| certain regret down the road involves more than creating an
| OpenSSL cnf file, creating a root cert/key, and running with it.
| That said, it's a starting point. If you're looking to use more
| modern (i.e., faster) crypto than RSA keys, maybe check out my
| sping on a CSR generator wrapping `openssl`, available at
| https://johannes.truschnigg.info/code/tls_req_gen
|
| If you need a self-signed cert instead, maybe try
| https://johannes.truschnigg.info/code/tls_cert_gen
| jordemort wrote:
| I really like step[1] and step-ca[2] for this, it's a lot less
| fiddly than having to drive OpenSSL directly.
|
| 1. https://github.com/smallstep/cli
|
| 2. https://github.com/smallstep/certificates
| gclawes wrote:
| And they support ACME. I've been running a smallstep CA off of
| a Nitrokey HSM 2[1] w/ PKCS #11 for my homelab for a few years
| now
|
| 1. https://shop.nitrokey.com/shop/product/nkhs2-nitrokey-
| hsm-2-...
| wejn wrote:
| That's really neat, thanks for the pointer. ;)
| codetrotter wrote:
| I run a squid proxy with TLS intercept on a raspberry pi, with my
| own CA.
|
| I have things set up so that the RPi connects to a WiFi, and then
| a cable from the RPi goes to another WiFi router.
|
| I connect my MacBook Pro to that other router.
|
| This way the MacBook Pro cannot reach the internet.
|
| Then I set the http and https proxy configs in Firefox so that it
| goes via the squid on the RPi. And I have the root CA from the
| RPi trusted in Firefox.
|
| Additionally I have set some env variables and added my root CA
| cert to some cert storages on the computer, so that git can clone
| via squid, and I can install and update things with brew etc.
|
| It works great :D
|
| But then I tried to set up my iPhone to also connect to that
| WiFi. I think I managed to trust my root CA on the phone. But I
| couldn't manage to set up the http/https proxy on the iPhone and
| so for now only the MacBook Pro can use it, and not the iPhone
| denysvitali wrote:
| You can use a transparent proxy to avoid this
| lini wrote:
| macOS uses certificate pinning for some _.apple.com_ and
| _.itunes.com_ sites. If you pass all your traffic through the
| proxy, some stuff like the app store will not work. Do you
| bypass the proxy for those or just let them fail?
| codetrotter wrote:
| I do that on purpose. I don't want macOS itself to reach the
| internet. Only Firefox, brew, etc
| alexeldeib wrote:
| I think iOS has http proxy settings in the wifi configuration
| for a given network? Haven't tried recently.
| JackGreyhat wrote:
| Easy-rsa to the rescue. Been using it for a while, works great
| and makes life easier :)
|
| Link: https://github.com/OpenVPN/easy-rsa
|
| Summary from that page:
|
| easy-rsa is a CLI utility to build and manage a PKI CA. In
| laymen's terms, this means to create a root certificate
| authority, and request and sign certificates, including
| intermediate CAs and certificate revocation lists (CRL).
___________________________________________________________________
(page generated 2023-09-16 23:00 UTC)