Welcome to Software Development on Codidact!
Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.
GnuTLS config for my own root CA, for use on internal server
I am trying to generate my own root CA certificate.
Context
My goal is to sign an intermediate CA with this certificate, and then install the intermediate CA on my own client machines. The intermediate CA will be used to sign a server on my private LAN. The server has no inbound route and cannot be seen from the public internet. I use the server to run my own personal services for my family.
Code (config)
I use gnutls with the following config:
# https://gnutls.org/manual/html_node/certtool-Invocation.html#certtool-Invocation
# These don't actually exist but I assume it doesn't matter
cn = "nosuchdomain.com"
organization = FakeCompanyName
country = US
state = California
locality = "San Francisco"
expiration_days = 3650
dns_name = "nosuchdomain.com"
ca
cert_signing_key
The command to generate is:
certtool \
--generate-self-signed \
--load-privkey /path/to/private/key \
--template /path/to/config \
--ask-pass \
--outfile /path/to/root/cert
Review goals
My goal is to create my own root CA for the purpose of setting up TLS on my own server that is only accessible from my own LAN. I will not have clients install this root CA, rather, it will be used to create an intermediate CA which is not self-signed and restricted to certain domains.
Is there anything I should change in this config, whether to avoid bugs or to be more aligned with best practices?
2 answers
Does GnuTLS support CA Name Constraints (RFC 5280, 4.2.1.10), so you can limit the valid domains directly in the root CA?
I'm not aware of any CAs that self-limit this way,[1] except for when the US government tried (unsuccessfully?) to get one approved by the CA/B forum for .gov and .mil. Name Constraints would give country-specific CAs the ability to issue certificates for their ccTLD, but could exclude them from globally-shared ICANN TLDs or other countries' ccTLDs.
-
It is also worth noting that Mozilla proposed enforcing name constraints external to the CA certificates, but that led to fiery discussion about entrenching current CAs that could issue for
.org,.com, etc. when new ones would have to beg to do so. ↩︎
0 comment threads
For future readers - based on input from Michael, and some research that was spurred by that improved version, this is the final config I arrived at:
# https://gnutls.org/manual/html_node/certtool-Invocation.html#certtool-Invocation
cn = "nosuchdomain.com"
organization = FakeCompanyName
country = US
state = California
locality = "San Francisco"
# In 2020, Apple started refusing certs longer than 1 year: https://support.apple.com/en-us/102028
# Others followed suit. However, as of Mar 2024 this is for real CAs only, not
# user-installed certs
expiration_days = -1
dns_name = "nosuchdomain.com"
nc_permit_dns = my.cool.website.com
nc_permit_dns = alternate.address.org
ca
cert_signing_key
In the past (1-2 years ago) I had gotten errors about name constraints in the root CA, so I had to leave it all powerful. This introduced a security hole where after installing my root CA, an attacker who gains access to the root CA key could impersonate any site like google.com. I had to use an intermediate CA instead. After the suggestions here, I tried and found that apparently root CAs can have name constraints, and indeed browser do error out when they see a server cert for a disallowed domain. This allowed me to cut out the intermediate CA which simplified things quite a bit.
I elected to remove the expiration. These days, browsers are trying to demand shorter expiration periods, to encourage site admins to automate rotation of certs in case of a leak. This requirement is imposed only for real CAs, not user-made CAs like the one here. Further, for private use like this, there is not much security benefit from expiration dates, because if I discover I've been compromised I can directly notify all clients anyhow. On the other hand, it's convenient not having to reinstall the root CA every year on each machine.
0 comment threads
1 comment thread