Running one’s own root Certificate Authority in 2023

https://wejn.org/2023/09/running-ones-own-root-certificate-authority-in-2023/

by jandeboevrie • 3 years ago

216 161 3 years ago

NegativeK2• 3 years ago

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• 3 years ago

Did you use elliptic curve instead of RSA?

fiddlerwoaroof6• 3 years ago

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.

punkybr3wster• 3 years ago

I’ve also struggled with this. Is there an elegant solution that you’re aware of? Everything I’ve tried feels really rickety.

moondev• 3 years ago

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

xg155• 3 years ago

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.

sneak3• 3 years ago

Why not register a domain, get a cert for it, and point it at 127.0.0.1? Then nothing can complain.

woodruffw6• 3 years ago

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...

mirchiseth• 3 years ago

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.

wejn8• 3 years ago

A friend of mine runs dns01 thusly: https://ipng.ch/s/articles/2023/03/24/lego-dns01.html

taskforcegemini• 3 years ago

do you use https/have a cert in your webserver as well, or just on the proxy?

petronio• 3 years ago

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.

psd1• 3 years ago

I found LE + CF DNS trouble-free.

Dockerfile:

``` FROM certbot/certbot RUN pip3 install certbot-dns-cloudflare cloudflare ```

docker-compose.yml:

``` volumes: - ${CREDENTIALS_DIRECTORY:-.}/cloudflare.ini:/cloudflare.ini - ${STATE_DIRECTORY:-./certbot}/:/etc/letsencrypt/ - ${LOGS_DIRECTORY:-/var/log/certbot}/:/var/log/letsencrypt/ command: " \ certonly \ --non-interactive \ --agree-tos \ --email postmaster@foo.bar \ --preferred-challenges dns-01 \ --dns-cloudflare \ --dns-cloudflare-credentials /cloudflare.ini \ --dns-cloudflare-propagation-seconds 30 \ -d foo.bar,*.foo.bar" ```

cpach2• 3 years ago

This ACME client looks promising, but I haven’t tried it yet: https://github.com/go-acme/lego

soraminazuki• 3 years ago

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.

hnarn• 3 years ago

I went with DNS based Let's Encrypt for internal certificates, since I'm okay leaking my internal DNS names.

Lets Encrypt offers wildcard certificates, there is no reason to have internal DNS records exposed.

wejn8• 3 years ago

Thanks, I've incorporated the name constraints into the article now. (it is indeed supported by Apple and FF just fine)

NegativeK2• 3 years ago

Very nice!

nemo2• 3 years ago

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...

xg155• 3 years ago

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.

nemo2• 3 years ago

Looking into it further, that's actually Apple's policy as well.

morpheuskafka• 3 years ago

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.

wejn8• 3 years ago

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• 3 years ago

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• 3 years ago

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• 3 years ago

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

wejn8• 3 years ago

That's really neat, thanks for the pointer. ;)

gclawes• 3 years ago

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-...

toastal• 3 years ago

Nice to see open source hardware token usage in the wild.

op00to• 3 years ago

Can you please give bullet points of your CA setup and more broadly your home lab? It sounds … awesome.

infogulch4• 3 years ago

Wouldn't it be nice if LetsEncrypt could issue you a (1) name constrained, (2) 90-day limited intermediate CA with just the (3) DNS-01 challenge? I argue that such an intermediate CA would have no more authority than a wildcard cert which you can get today, so they should be able to issue it. [1] Everything supports name constraints now, which used to be an issue but isn't anymore. [2]

Then stick it in step-ca and issue all your certificates with internal ACME.

This would solve a lot of problems, such as leaking private hostnames in the certificate transparency log, or hitting issuance rate limits on LE servers.

[1] https://news.ycombinator.com/item?id=29811552

[2] https://bettertls.com/

woodruffw6• 3 years ago

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-user use, it’s IMO understandable that this isn’t a priority for the CA ecosystem to support.

(The use case of circumventing CT is probably a non-starter as well. The Web PKI doesn’t want CT loopholes!)

capitol_• 3 years ago

It would be impossible to enforce that issued certs are submitted to certificate transparency logs and this would break the security model around the ca system.

michaelt2• 3 years ago

Wouldn't it be nice if LetsEncrypt could issue you a (1) name constrained, [...] intermediate CA

Unfortunately, name constraints don't work in all clients. Name constraints are an 'extension' to the standard and supporting them is optional.

According to [1]

Before relying on this solution to protect our users, we wanted to make sure browsers were really implementing Name Constraints verification and doing so correctly. The initial results were promising: each of the browsers we tested (Chrome, Firefox, Edge, and Safari) all gave verification exceptions when browsing to a site where a CA signed a certificate in violation of the constraints.
However, as we extended our test suite beyond basic tests we rapidly began to lose confidence. [...] The result was that every browser (except for Firefox, which showed a 100% pass rate) and every HTTPS client (such as Java, Node.JS, and Python) allowed some sort of Name Constraint bypass.

And even if someone went around and fixed every TLS library in the world, there'd still be millions of devices out there that never get security updates, like smart fridges and ancient android tablets.

There's a major chicken-and-egg problem: Because nobody will issue name-constrained certificates, clients don't have much reason to prioritise it as a feature. And because name constraints don't work perfectly everywhere, nobody will issue name-constrained certificates.

I doubt we'll ever see a trusted CA issuing name constrained intermediate CA certificates.

Of course, they could offer an API where if you've passed auth for *.example.com you can issue a cert for any subdomain below that without any further validation...

[1] https://netflixtechblog.com/bettertls-c9915cd255c0

mattpallissard• 3 years ago

I completely agree that dealing with openssl is fiddly at best when you RYO CA. But, if your org knows how PKI works it's not a big deal; a bash script or two in the simple case or a flask app at most complex.

If your org doesn't know how PKI works shouldn't you be paying a vendor that does?

codetrotter2• 3 years ago

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

alexeldeib• 3 years ago

I think iOS has http proxy settings in the wifi configuration for a given network? Haven’t tried recently.

lini• 3 years ago

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?

codetrotter2• 3 years ago

I do that on purpose. I don’t want macOS itself to reach the internet. Only Firefox, brew, etc

denysvitali• 3 years ago

You can use a transparent proxy to avoid this

JackGreyhat• 3 years ago

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).

suckitsam• 3 years ago

It's funny how I go from "YEAH! CA's SHOULD be a quick one-liner!" to "Should laymen be generating Root CAs?" inside of like 10 seconds of scrolling.

obnauticus• 3 years ago

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.

n0n• 3 years ago

Yes, please! I would be interested. Currently i'm fiddling around with vault as an ICA, so this sounds like a good next step

dmayle• 3 years ago

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

processunknown• 3 years ago

Please do

temren• 3 years ago

an article like that would be great!

Lienetic• 3 years ago

+1 sounds like an interesting read

andrewstuart2• 3 years ago

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.

jiggawatts8• 3 years ago

“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• 3 years ago

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.

firesteelrain5• 3 years ago

Azure will let you tap into a HSM too

jiggawatts8• 3 years ago

You just answered a rant about too much ceremony by linking to an entire service that costs a staggering USD 400 / month. That’s the cost of an FTE in like half the world… to issue what are essentially “fat passwords”.

Imagine with a straight face trying to sell someone a “password generator service” when in reality that’s just a one line script snippet.

The disconnect between the physical reality on the ground and how it is treated by industry is just absurd.

Ref: https://aws.amazon.com/private-ca/pricing/

Getting a signed cert issued should be a one-liner script referencing an AWS KMS or an Azure KeyVault!

gorkish• 3 years ago

It’s about damn time that we should be able to get intermediate signing certs that are domain limited from a public ca and issue out own “real” certs. This is fully supported in the standards. Anyone offering this product affordably yet?

diarrhea4• 3 years ago

Interesting idea. What use cases would this make easier or even possible? At first, it sounds like more work (you’re now your own CA but without full freedom of a truly self hosted one).

Dragging-Syrup• 3 years ago

The other “half” of the issue is getting the os, browsers, and devices to support the standard as well. That’s a whole other can of worms.

c2h5oh• 3 years ago

Domain limiting is implemented using x.509 cert nameConstraints, which the last time I've checked were not supported on Apple devices..

Edit: has been fixed in osx 10.13.3. Idk about iOS.

diarrhea4• 3 years ago

A password is a secret. A certificate is fully public (it’s useless if not). I don’t see how they’re similar in that dimension. Or how certificates are possible without a third party (a core reason for all the ceremony). Passwords get away with not needing a third party involved because they’re a prearranged process. Certificates aren’t, I need to be able to hit any website at any point, for the first time.

jiggawatts8• 3 years ago

The key phrase here is internal use. Think authentication between two micro services, not HTTPS for someblog.com.

The third party in this case is just a file: the internal CA key.

Try to think of this in the following terms: the issued certs are just signed tokens, nothing more. They’re also conveniently a public-private key pair, but that’s not the point.

The point is that if you used a 1kb random password for service to service auth and someone tried to sell you a $400/mo service to generate them, you’d laugh in their face and then have security escort them from the building.

Sprinkle a tiny bit of cryptography on top and suddenly people think $4,800 annually is a bargain for 1kb passwords.

I can buy a decent used car for that kind of money.

gregmac• 3 years ago

A certificate is a key pair with both a public and private part. The private key is needed to sign data, while the public key can only validate that signature.

You can think of the private key as equivalent to a password, in the context the parent is talking about.

mdekkers3• 3 years ago

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 assertion.

The whole _point_ of a PKI is trust, and why would this be any different for internal systems?

jiggawatts8• 3 years ago

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.

firesteelrain5• 3 years ago

HashiCorp Vault supports being an ACME server. Why not use that?

rigrassm• 3 years ago

To be fair, this was only introduced in the most recent major version release not too long ago.

But I agree, it's a great feature and worked as advertised after following their guide. Doesn't sound like a ringing endorsement but in my experience it's rare for custom CA tooling to Just Work and until now none of them resulted in a fully functional ACME provider to serve up your certs.

firesteelrain5• 3 years ago

I agree. I just set it up the other day in a container. It’s going to be our ACME provider. It is stupid easy

wejn8• 3 years ago

Because:

1. ACME is a dumpster fire prone to mitm attacks.

2. without HSM (an additional investment) it's super bad idea to host your root CA signing key somewhere.

firesteelrain5• 3 years ago

This is an internal, airgapped network.

We stood up the root CA, created the certificate, imported it, then destroyed the root CA. It’s a common security practice. Root CA can then never be compromised

sacnoradhq• 3 years ago

OPNsense has built-in easy CA/PKI management.

js2• 3 years ago

Yahoo's in-house CA for doing this at scale:

https://www.athenz.io/

e12e2• 3 years ago

"Only" missing how to safely distribute, trust and revoke/renew the root cert - and how to enforce/distribute revocation lists for certs...

wejn8• 3 years ago

"only" out of scope.

But based on the comments here, I guess you could use the smallstep CA with Nitrokey HSM if that's your jam...

e12e2• 3 years ago

Well, the title says: "Running one's own root Certificate Authority in 2023".

"Running a CA" is pretty much dominated by managing certificates? Including distribution and revocation - not just issuing?

ivlad2• 3 years ago

Using RSA in 2023 for a CA that is expected to be around for an extended period of time is just silly.

ECDSA 384 or longer depending on the expected CA lifetime and security margins (see https://www.keylength.com/) is a saner choice.

Also, https://blog.trailofbits.com/2019/07/08/fuck-rsa/

m1keil• 3 years ago

Makes no difference in his setup as he can rotate the CA and the rest of the infrastructure quickly.

unethical_ban2• 3 years ago

https://hohnstaedt.de/xca/

This doesn't cover deployment of the CAs to clients, but it's easy free desktop software.

1vuio0pswjnm7• 3 years ago

Trivia question: What is the limit, if any, for how many DNS names (SANs) one can include in a single self-signed certificate. It is common to see TLS proxies that will generate certificates on the fly as SNI in clientHell is received. Is this due to a limit on how many SANs one can include in a single certificate.

(Maybe the performance degradation of generating a certificate on the fly is less than using a certificate that includes 100s of SANs.)

chrisweekly• 3 years ago

I think user-perceptible performance degradation might set a lower practical ceiling than purely technical limitations would. I've seen as many as ~200 SANs on a single cert -- but I'm not claiming any special expertise or insights.

entuno• 3 years ago

I'm sure sure about a hard limit in the x509 standard (would need to dig into the RFCs) - but the BadSSL site has two test domains that have certificates with 1,000 and 10,000 SANs respectively:

https://1000-sans.badssl.com

https://10000-sans.badssl.com

1,000 works in Firefox and Chromium, but 10,000 gives `SSL_ERROR_RX_MALFORMED_HANDSHAKE` in Firefox, and `ERR_SSL_PROTOCOL_ERROR` in Chromium. OpenSSL won't connect to it either - it gives `read_state_machine:excessive message size:ssl/statem/statem.c:610`

So in practical terms, the answer seems to be somewhere between the 1,000 and 10,000.

remram2• 3 years ago

I tend to treat service TLS certificates more like shared keys than PKI. Too many pieces of software don't handle revocation, it's easier to regenerate the CA and the entire set of certificates when you change your setup.

goku124• 3 years ago

The better solution is to do what vault does. Use only ephemeral certificates for servers and clients. It wouldn't be too hard to change them every week or so using the ACME protocol.

remram2• 3 years ago

ACME has a revocation workflow. Having my lost certificates be valid for a week is still unacceptable.

kubanczyk• 3 years ago

If you control all the clients/browsers (i.e. you can immediately modify the required trust stores), you don't have any use for PKI whatsoever.

PKI's use case begins with shipping a trust store into the wild, where it will run unchanged for months or years.

galaxyLogic7• 3 years ago

Is 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?

rurban• 3 years ago

mkcert is the easiest

goku124• 3 years ago

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

galaxyLogic7• 3 years ago

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?

galaxyLogic7• 3 years ago

I'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 update that certificate part ever?

alexvitkov• 3 years ago

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.

galaxyLogic7• 3 years ago

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.

withinboredom3• 3 years ago

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 like C# MAUI or whatever language you’re familiar with. Your users will thank you for a smooth experience.

jimmyspice• 3 years ago

what's wrong with using a dynamically allocated port?

galaxyLogic7• 3 years ago

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.

goku124• 3 years ago

Looks like step-ca/step-cli [1] and mkcert [2] have been mentioned. Another related tool is XCA [3] - a gui tool to manage CAs and server/client TLS certificates. It takes off some of the tedium in using openssl cli directly. It also stores the certs and keys in an encrypted database. It doesn't solve the problem of getting the root CA certificate into the system store or of hosting the revocation list. I use XCA to create and store the root CA. Intermediate CAs signed with it are passed to other issuers like vault and step-issuer.

[1] https://smallstep.com/docs/step-ca/

[2] https://github.com/FiloSottile/mkcert

[3] https://hohnstaedt.de/xca/

linsomniac• 3 years ago

Shameless plug, there's also https://github.com/linsomniac/rgca

I've been using it at work for the last year for our certs and it's been quite nice. It can do pre/post hooks as well, so it directly commits the updated CA serial files to our git repo.

rad_gruchalski3• 3 years ago

I like cfssl: https://github.com/cloudflare/cfssl.

Anon_Forever• 3 years ago

HashiCorp Vault is a one-stop shop for this. It's an amazing piece of software.

lazyweb• 3 years ago

Agreed. I've introduced an internal, selfs-signed CA using Vault, ansible and Jenkins for my personal infrastructure. Issues certs via pipeline job and restarts / reloads affected target services if needed.

I might do a writeup soon on this, it's not even that complicated.

lakomen• 3 years ago

I've done this previously, about 10 years ago, for a distributed kv store I wrote.

Not a lot of fun.

Meanwhile, I'm guessing, there are new useful utilities out.

One I remember was easyCA or was it easyPKI?

lostmsu• 3 years ago

This is more like "making and installing own root certificate".

I expected the article to be about actually being a certificate authority that every browser will trust by default.

leonletto• 3 years ago

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?

wkat4242• 3 years ago

It's actually really difficult to import custom CAs now on Android. Since version 7 you can only import into the user store and apps ignore this one by default so it's pretty useless.

fsmv• 3 years ago

I made a web server / microservices thing that issues certs for clients from a CA root it automatically generates. Then internal reverse proxy connections use that cert so the whole path is TLD encrypted with full cert validation.

https://github.com/fsmv/daemon

Running one’s own root Certificate Authority in 2023

Related Stories