ssl-cert group - what users should be part of it?
divStar opened this issue · comments
Hello,
first and foremost: thank you for making this! I am currently fiddling with SSL since I want to create a local domain (within my own network) and I'd like all my services to use SSL. Since my internal domain will be different from the domain I own, I thought I should have create a CA and manage one or several certificates myself and since I will only have about lets say 10 services altogether, this should not be a problem.
When trying to use your script, I saw, that it relies on a group called ssl-cert. What users should be in that group? Every user, who potentialls needs to access that location? Or just the user I am using to run the scripts?
I am using Docker and currently I have mounted /etc/ssl to every container, that needs to access the cert and key or the pem files. However: since at the moment I am just using a self-signed certificate, it seems, that even after importing it, I still get a warning saying, that the certificate is not trusted.
Thus I figured I need a CA, which then issues a certificate per service (or perhaps a wildcard certificate), in order to have a chance at establishing a HTTPS connection to the service without getting all the warning screens (which would certainly be appropriate - if I was exposing anything over the internet).
And while I am at it: do I need to do anything extra if I want the subjectAltName (SAN) to be set? And can I enhance the validity date of the certificate to be much longer so that I will not have to renew it too often?
Thank you very much in advance!
it is really all about the private Root CA.
Many apps/programs have specialized insertion procedure of your Root CA into their trusted certificate database.
some of the most recent support to adding your private Root CA can be described here:
- Firefox https://support.mozilla.org/en-US/kb/setting-certificate-authorities-firefox and https://techdocs.broadcom.com/us/en/symantec-security-software/web-and-network-security/web-security-service/help/ssl-certs-policies/ssl_firefox_cert_ta.html
- Windows https://docs.druva.com/Knowledge_Base/inSync/How_To/How_to_add_the_CA_certificate_as_a_trusted_root_authority_on_a_Windows_device
- macOS https://www.bounca.org/tutorials/install_root_certificate.html
Obviously, some more digging is required to get the command line approach of doing the same insertion of your private Root CA so you can automate your Docker creation needed for testing.
The thing that I have to remember often (its me), is that prefs.js gets regenerated within an existing Firefox profile each time I start up, and that this safer user.js is not the suitable insertion point of this private Root CA; one must do the "enterprise" setup.
Once the private Root CA gets installed properly, the Firefox browser warning goes away.
also, with regard to "which user"? I often add this ssl-cert as a supplementary group toward my own non-root user (non-root but sudo'able admin) account and used that non-root admin for all my setup needs. but i used a different account (test) for testing.
Redhat exposed the “override” mechanism provided by Firefox for private Root CA which I have not tried on other Linux distros.
Let’s Encrypt detailed this procedure using command line for Firefox
Gentoo and Arch Linux distros typically have the best HOWTOs documentation:
https://wiki.gentoo.org/wiki/Certificates
https://wiki.archlinux.org/title/Network_Security_Services
then there are hacking tools like MitMProxy who do this very often:
Let me know if this answers your question so that I can closed this issue.
one last thing, it is probably a better idea on Linux platform to use a Redhat (or IBM) version of Firefox for your private Root CA needs.
https://bugzilla.mozilla.org/show_bug.cgi?id=1600509
BUT Ive been told that for non-Redhat distro, if you call a library function of pk11-kit-trust,OR study the NSS library, you can still do the insertion of private Root CA. Problem is that location and methods of interacting with NSS library differs from one distro to another. https://bugzilla.mozilla.org/show_bug.cgi?id=1505026
Thank you for all the information! I think the question about setting subjectAltName and the other about prolonging the certificate's validity still aren't as clear to me (last paragraph of my issue).
Other than that this was a huge chunk of useful information, that perhaps should go to the readme or similar file (e.g. integrating-certificates.md or something). Since I haven't tried it out yet, I cannot yet tell what exactly was useful.
I am not a big fan of star-domain approach (as a security researcher). I tend to stay away from star.
But you can always define *.your-domain-name as a SAN, but only for HTTP/HTTPS and TLS related connections; that includes POP3S, IMAP4S, as well as DNS-over-HTTPS/DNS-over-TLS. Which should cover about 90.0% of most hobbyists needs.
There are some protocols that wont work with starred SAN such as certain WebDAV (nextCloud, ownCloud), Matrix messaging server, IPSec, Wireguard, certain VPN server.
I wrote something about SAN.... https://egbert.net/blog/articles/openssl-subjectAltName.html
Something else, you CAN use reserved address in subjectAltName IP: variable data entry.
The requirement is MUST (not), not SHALL (not). So, feel free to go ahead and use reserved IP address subnets/addresses in your private net.
Excerpt:
IP MUST have an iPAddress containing the IP address of a server. IP address shall not be a reserved IP address.
A tentative list of reserved IPv4 addresses not to use are: 0.0.0.0/8, 10.0.0.0/8, 100.64.0.0/10, 127.0.0.0/8, 169.254.0.0/16, 172.16.0.0/12, 192.0.0.0/24, 192.0.2.0/24, 192.88.99.0/24, 192.168.0.0/16, 198.18.0.0/15, 198.51.100.0/24, 203.0.113.0/24, 224.0.0.0/4, 233.252.0.0/24, 240.0.0.0/4, 255.255.255.255/32.