Skip to content

What do you use for SSL on development domains?

Web Hosting by armstrongvds 29 replies 2.7K views
#21

Curious if you landed on mkcert with shared CA or went another direction. I've been using a similar setup with KnownHost boxes and the trust-store automation was the annoying part. Puppet ended up handling it but ARM had some edge cases with the NSS db paths.

kat_fold said:
Mkcert with a shared internal CA cert (not key!) is what most teams land on.
This is where we ended up too. The "not key" distinction is important — saw a team get that wrong once and it was a mess to untangle. The 30-day thing you mentioned with local.test certs sounds like whatever tool was generating them had a hardcoded short lifetime. Mkcert defaults to 10 years which removes that headache entirely. Would still love to hear what you went with, especially at that scale with 20 devs.

#22

Been quiet here for a month and a half, anyone land on a solution?

I actually got that Altra benchmark sorted — 2.2k was RSA-2048 sign with OpenSSL 3.0, not exactly apples to apples with M2

For the actual thread topic, we ended up going with mkcert + shared CA at my last gig and it was fine until someone committed the CA key to a public repo

Now I'm at a shop using Vultr's internal CA product and it's basically mkcert-as-a-service with proper audit trails. Not free but the compliance team sleeps better

Curious if anyone's tried GreenCloudVPS's dev certs? They keep emailing me about it

#23
kat_fold said:
Mkcert with a shared internal CA cert (not key!) is what most teams land on.

We ended up going exactly this route. Ansible playbook pushes the CA cert to the trust store on first boot, devs never touch it.

One gotcha: Firefox on Ubuntu ignores the system trust store by default, so we had to add a second task for the NSS DB. Easy to miss if you're only testing Chrome.

van3 said:
2.2k signs/sec on Altra?

Haven't benchmarked against M2 but for our workload (Rails + Sidekiq) the single-thread perf gap is real. Compilation is noticeably slower than my old Intel box. The throughput wins once you're running parallel jobs though.

Did anyone actually solve the 30-day expiration problem without going full private CA? Let's Encrypt staging still seems like a treadmill.

one small ping for man...
#24

57 days, guess the SSL problem solved itself or everyone switched to HTTP.

kat_fold said:
Mkcert with a shared internal CA cert (not key!) is what most teams land on.

Small correction: the CA *key* still has to live somewhere to sign new certs. If you're sharing the CA cert around for trust that's fine, but protect that signing key like production. HSM if you're paranoid, airgapped machine if you're practical.

For the ARM Ampere fleet specifically, mkcert builds fine but you'll want to cache the binary in your artifact repo. Don't hit GitHub from 20 CI runners every morning.

Anyone actually got this running at scale? Curious if you hit rate limits or trust store edge cases on the Altra boxes.

No logs, no proof. I have logs.
#25

Did anyone actually benchmark the ARM signing speed or are we still guessing?

van3 said:
2.2k signs/sec on Altra? I want to see that benchmarked against the M2
I ran our internal CA on a KnownHost nano instance last month and got nowhere near that, but I was using soft HSM. Curious if that's with dedicated crypto extensions or what.

Also @armstrongvds did you ever settle on mkcert vs staging? 62 days later I'm guessing you picked one.

RAID 1: because paranoia pays
#26

I owe you all a follow-up. We ended up going with mkcert + shared CA cert exactly as kat_fold described, pushed out via our config management (we use a custom Ansible setup targeting the Ampere boxes). The one-time trust install was the right call. Per-dev certs now auto-generate on first project clone via a Makefile target. Zero manual steps after onboarding. Still curious about that signing benchmark though, van3 — our Altra Max boxes are doing about 1.8k signs/sec with OpenSSL 3.0 and I wonder if there's a tuning trick we're missing.

one small ping for man...
#27

72 days — did anyone actually solve this?

kat_fold said:
Mkcert with a shared internal CA cert (not key!) is what most teams land on

We went this route at my last gig but hit a wall with WSL2 + Docker Desktop, the trust store inside containers never saw the host CA properly

Has anyone wired this up cleanly with Contabo's container runtime? Their docs mention custom CA injection but it's enterprise-tier only

Also curious if the ARM Ampere angle changed anyone's mind on local signing speed, or if that's just bench racing like van3 said

#28

Did anyone actually benchmark the Altra against M2 for cert signing?

van3 said:
2.2k signs/sec on Altra? I want to see that benchmarked against the M2

We've got a mix of Ampere boxes and M2 Pros in our lab and I'd be curious if the gap is as big as the price suggests.

Also @armstrongvds did you end up going with the mkcert shared CA route? 87 days later I'm guessing you either solved it or found a new thing to be annoyed by.

learning on $5 VPS and prayers
#29

Still curious about the Altra numbers — anyone actually run OpenSSL speed on those Ampere boxes?

kat_fold said:
Mkcert with a shared internal CA cert (not key!) is what most teams land on

Did you ever solve the ARM trust-store automation? Last I checked mkcert's -install still needed sudo on Linux and our Ansible playbook for it was flaky on Ubuntu 22.04

Also 91 days later — did the 30-day cert problem just… Go away, or did you end up on Vultr's dev CA thing

#30

Did anyone actually solve this for the ARM Ampere boxes

kat_fold said:
Mkcert with a shared internal CA cert (not key!) is what most teams land on

We tried this on our InterServer dev fleet and the trust store step still breaks every Ubuntu point release

Gave up and went with GreenCloudVPS's internal CA feature, dev certs auto-enroll via their agent

Not zero cost but the time saved

Post a reply

You need an account to reply. Log in or register to join the conversation.

Post reply Preview Save draft