Does Let's Encrypt offer a service similar to GlobalSign IntranetSSL for non-public domains?
- jss
No, Let's Encrypt only provides publicly trusted certificates.
4 Likes
Moving this from Help to Feature Requests.
Can Let's Encrypt offer a service similar to GlobalSign IntranetSSL for non-public domains?
- jss
the certificates are issued using GlobalSign non-public CAs
In order for IntranetSSL certificates to be trusted by browsers or server-to-server communications, the root(s) will need to be pushed out via GPO or related enterprise tools so clients will not receive warning messages.
They're talking about a private managed CA.
You can have a private CA by yourself, but you have to manage it yourself. Check minica, picoca, and step-ca.
This sounds like it's out of scope for Let's Encrypt.
The alternative is to use intranet.example.com as a suffix and issue certificates via dns-01 for nodename.intranet.example.com, which is a public FQDN even if it's not publicly reachable.
5 Likes
2 Likes
I was going to post the link I've probably posted dozens of times to the Raspberry Pi-based local CA, but I see it's already in that other thread. It continues to work well for me.
4 Likes
For private domains (intranet) I use step-ca + trefik (to offer HTTPS revers proxy) since a couple of years at several customers and this solution work very well!
1 Like
A good solution for internal use is:
Just use 4096 instead of 2048, and set days to 365 (I think 398 is max)
I changed DNS.1 = name to IP.1 = IP on website in script under [alt names] to have it working OK.
Install root-cert in every computer and CA-selsigned cert in your computer with websites.
In chrome it worked perfect, but I had to import root-cert to Firefox or accept the local CA.
I tested step, but that didn't work as good as this solution.
Why?
Also, the guide you've linked to requires a lot of manual steps (although there is a script mentioned at the bottom). If I require a"local" certificate, I too use manual commands, but for larger operations I'd recommend using a specific tool such as mentioned above.
I myself have used the guide at OpenSSL Certificate Authority — Jamie Nguyen which uses the openssl ca command. This enables you to also sign revocation lists et cetera.
4 Likes
If you want to learn, fine. If you just need your private CA easily, just use
Also, as @Osiris noticed, if you don't like RSA 2048 bit it's probably more useful to go with elliptic curves (P-256 or P-384)
3 Likes
For local small size environments it probably really doesn't matter much at all.. So I'm interested to hear why using a 4096 bit key would be recommended by @johmor52
3 Likes
Indeed, CPU cycles are more important anyway in those environments. P-256 should be faster than RSA 2048 on most modern processors.
I mean, this is on my phone:
~ $ openssl speed rsa2048 rsa4096 ecdsap256 ecdsap384
--- removed stuff ---
sign verify sign/s verify/s
rsa 2048 bits 0.003707s 0.000102s 269.7 9841.8
rsa 4096 bits 0.026402s 0.000395s 37.9 2531.6
sign verify sign/s verify/s
256 bits ecdsa (nistp256) 0.0001s 0.0002s 15419.7 4918.8
384 bits ecdsa (nistp384) 0.0025s 0.0019s 404.7 517.4
2 Likes
I would love to have a certificate like this without the public Certificate Transparency (CT) logs.
1 Like
Nothing is holding you back. Certificates signed by non-trusted roots wouldn't be accepted by a CT log anyway.
3 Likes
I use 4096 because of:
Code signing changes in 2021
Starting from May 28, 2021, 14:00 MDT (20:00 UTC), DigiCert will require 3072-bit RSA keys or larger for code signing certificates.
That's why 2048 isn't good enough
1 Like
DigiCert is a publicly trusted CA. Do they have a specific reason to require 3072 bits for code signing certificates? I.e., are certificates using 2048 bit keysizes not trusted in specific situations by some softwares?
If the latter is not the case, DigiCert can require all they want, but that wouldn't influence non-publicly trusted local CAs what so ever.
4 Likes
Yes, the Baseline Requirements for Code Signing (Baseline Requirements (Code Signing) – CAB Forum) specifies that RSA 3072 bit or greater must be used for all (leaf) code-signing certificates after June 1, 2021. [4096 bits for roots and intermediates]
Root programs such as Microsoft (may) have additional requirements. For example, Microsoft currently has a phase-out plan for 2048-bit RSA roots (by 2030 no active code-signing root shall have a 2048 bit key).
A probable reason the root programs and BRs are so strict regarding code-signing certificates is because signatures created by this type of certificate might have to remain secure for decades (a signature on a binary created in e.g 2022 might still be verified in 2035+). This is different to other applications (like TLS) where signatures become irrelevant after expiration - code-signing can outlive the certificate by many years.
It's similar to (PKI/TLS) root certificates, which also tend to have long lifetimes - that naturally leads to larger keys being preferred "just in case".
None of this really matters if you're only working with web/TLS stuff, as lifetimes are significantly less here.
4 Likes
Thanks for that source @Nummer378 
Question remains: do validating libraries/softwares enforce these requirements? As the BR and root programs don't apply to local, non-trusted CAs.
5 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.