# Certificates for non-public domains
**URL:** https://community.letsencrypt.org/t/certificates-for-non-public-domains/172829
**Category:** Feature Requests
**Created:** [February 27, 2022, 8:17pm UTC](https://community.letsencrypt.org/t/certificates-for-non-public-domains/172829 "2022-02-27T20:17:27Z")
**Posts on this page:** 19
**Page:** 1
### Author:  [@jon.stumpf](https://community.letsencrypt.org/u/jon.stumpf)
#### Post date: [February 27, 2022, 8:17pm UTC](https://community.letsencrypt.org/t/certificates-for-non-public-domains/172829/1 "2022-02-27T20:17:27Z")
Does Let's Encrypt offer a service similar to [GlobalSign IntranetSSL](https://www.globalsign.com/en/ssl/intranetssl) for non-public domains?
- jss
Ref:
[https://www.globalsign.com/en/ssl/intranetssl](https://www.globalsign.com/en/ssl/intranetssl)
---
### Author:  [@\_az](https://community.letsencrypt.org/u/_az)
#### Post date: [February 27, 2022, 8:27pm UTC](https://community.letsencrypt.org/t/certificates-for-non-public-domains/172829/2 "2022-02-27T20:27:58Z")
No, Let's Encrypt only provides publicly trusted certificates.
---
### Author:  [@jon.stumpf](https://community.letsencrypt.org/u/jon.stumpf)
#### Post date: [February 27, 2022, 8:31pm UTC](https://community.letsencrypt.org/t/certificates-for-non-public-domains/172829/3 "2022-02-27T20:31:57Z")
Moving this from **Help** to **Feature Requests**.
Can Let's Encrypt offer a service similar to [GlobalSign IntranetSSL](https://www.globalsign.com/en/ssl/intranetssl) for non-public domains?
- jss
---
### Author:  [@9peppe](https://community.letsencrypt.org/u/9peppe)
#### Post date: [February 27, 2022, 8:39pm UTC](https://community.letsencrypt.org/t/certificates-for-non-public-domains/172829/4 "2022-02-27T20:39:34Z")
> 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.
---
### Author:  [@jon.stumpf](https://community.letsencrypt.org/u/jon.stumpf)
#### Post date: [February 27, 2022, 8:46pm UTC](https://community.letsencrypt.org/t/certificates-for-non-public-domains/172829/5 "2022-02-27T20:46:14Z")
I found [this thread](https://community.letsencrypt.org/t/trusted-ssl-for-private-networks/149663) in **Help** which included your recommendation. I will follow this.
Thanks.
- jss
---
### Author:  [@danb35](https://community.letsencrypt.org/u/danb35)
#### Post date: [February 27, 2022, 11:50pm UTC](https://community.letsencrypt.org/t/certificates-for-non-public-domains/172829/6 "2022-02-27T23:50:15Z")
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.
---
### Author:  [@emericv](https://community.letsencrypt.org/u/emericv)
#### Post date: [February 28, 2022, 12:12pm UTC](https://community.letsencrypt.org/t/certificates-for-non-public-domains/172829/7 "2022-02-28T12:12:04Z")
👍
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!
---
### Author:  [@johmor52](https://community.letsencrypt.org/u/johmor52)
#### Post date: [March 12, 2022, 10:56am UTC](https://community.letsencrypt.org/t/certificates-for-non-public-domains/172829/8 "2022-03-12T10:56:25Z")
A good solution for internal use is:
> **[How to Create Your Own SSL Certificate Authority for Local HTTPS Development](https://deliciousbrains.com/ssl-certificate-authority-for-local-https-development/#why-https-locally)**
>
> Learn how to set up your own SSL Certificate Authority for local HTTPS web development.
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.
---
### Author:  [@Osiris](https://community.letsencrypt.org/u/Osiris)
#### Post date: [March 12, 2022, 11:19am UTC](https://community.letsencrypt.org/t/certificates-for-non-public-domains/172829/9 "2022-03-12T11:19:19Z")
> [@johmor52](#):
>
> Just use 4096 instead of 2048
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](https://jamielinux.com/docs/openssl-certificate-authority/) which uses the `openssl ca` command. This enables you to also sign revocation lists et cetera.
---
### Author:  [@9peppe](https://community.letsencrypt.org/u/9peppe)
#### Post date: [March 12, 2022, 11:27am UTC](https://community.letsencrypt.org/t/certificates-for-non-public-domains/172829/10 "2022-03-12T11:27:57Z")
If you want to learn, fine. If you just need your private CA easily, just use
- [minica](https://github.com/jsha/minica) or
- [picoca](https://github.com/april/picoca)
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)
---
### Author:  [@Osiris](https://community.letsencrypt.org/u/Osiris)
#### Post date: [March 12, 2022, 11:34am UTC](https://community.letsencrypt.org/t/certificates-for-non-public-domains/172829/11 "2022-03-12T11:34:57Z")
> [@9peppe](#):
>
> 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)
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
---
### Author:  [@9peppe](https://community.letsencrypt.org/u/9peppe)
#### Post date: [March 12, 2022, 11:37am UTC](https://community.letsencrypt.org/t/certificates-for-non-public-domains/172829/12 "2022-03-12T11:37:32Z")
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:
```nohighlight
~ $ 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
```
---
### Author:  [@saudiqbal](https://community.letsencrypt.org/u/saudiqbal)
#### Post date: [March 12, 2022, 2:29pm UTC](https://community.letsencrypt.org/t/certificates-for-non-public-domains/172829/13 "2022-03-12T14:29:48Z")
I would love to have a certificate like this without the public Certificate Transparency (CT) logs.
---
### Author:  [@Osiris](https://community.letsencrypt.org/u/Osiris)
#### Post date: [March 12, 2022, 2:32pm UTC](https://community.letsencrypt.org/t/certificates-for-non-public-domains/172829/14 "2022-03-12T14:32:23Z")
Nothing is holding you back. Certificates signed by non-trusted roots wouldn't be accepted by a CT log anyway.
---
### Author:  [@johmor52](https://community.letsencrypt.org/u/johmor52)
#### Post date: [March 12, 2022, 4:12pm UTC](https://community.letsencrypt.org/t/certificates-for-non-public-domains/172829/15 "2022-03-12T16:12:52Z")
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
---
### Author:  [@Osiris](https://community.letsencrypt.org/u/Osiris)
#### Post date: [March 12, 2022, 4:17pm UTC](https://community.letsencrypt.org/t/certificates-for-non-public-domains/172829/16 "2022-03-12T16:17:34Z")
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.
---
### Author:  [@Nummer378](https://community.letsencrypt.org/u/Nummer378)
#### Post date: [March 12, 2022, 5:47pm UTC](https://community.letsencrypt.org/t/certificates-for-non-public-domains/172829/17 "2022-03-12T17:47:39Z")
> [@Osiris](#):
>
> Do they have a specific reason to require 3072 bits for code signing certificates?
Yes, the Baseline Requirements for Code Signing ([Baseline Requirements (Code Signing) – CAB Forum](https://cabforum.org/baseline-requirements-code-signing/)) 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.
---
### Author:  [@Osiris](https://community.letsencrypt.org/u/Osiris)
#### Post date: [March 12, 2022, 5:50pm UTC](https://community.letsencrypt.org/t/certificates-for-non-public-domains/172829/18 "2022-03-12T17:50:00Z")
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.
---
### Author:  [@system](https://community.letsencrypt.org/u/system)
#### Post date: [April 11, 2022, 5:50pm UTC](https://community.letsencrypt.org/t/certificates-for-non-public-domains/172829/19 "2022-04-11T17:50:34Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.