This guide’s comprehensive up to the Deploy the Certificate section, but “You can now either deploy your new certificate to a server, or distribute the certificate to a client. When deploying to a server application (eg, Apache), you need to make the following files available” leaves no clear idea what to do to actually deploy it. Where should those files be avail, etc? Pointers to further resources would be helpful here,
Hello, I need to create Indirect CRL, could you pleas help us by providing the steps to do so.
Great writeup!!! Thanks.
Something caught my eye. In the intermediate configuration file in the appendix you have
[ req ]
x509_extensions = v3_ca
when I expected to see
[ req ]
x509_extensions = v3_intermediate_ca
because of the
pathlen:0 attribute only in the latter:
basicContraints = …, pathlen:0
Awesome works, Thanks a lot !
Thank you for great documentation.
I would suggest adding “copy_extensions = copy” to [ CA_default ] at intermediate/openssl.cnf to pass subjectAltName to signed certificate along with CRL.
Adding my thanks and appreciation!
For several years, I maintained a registry of assigned names and numbers for a software development organization: mostly OID’s and SNMP MIB’s. At one point, I prototyped an internal CA and published certificates as well. The registry structure followed Maven/Ivy conventions so that build/integration systems could download these artifacts. I followed this tutorial to set up the CA.
Jamie’s tutorial covers certificate generation but not so much about publication. Similarly, the aspects of provisioning servers and clients are not covered so much. I ran into the sort of problems you find in the comments such as how to bundle up a certificate chain and key for a given server.
I’ve published two GitHub projects covering:
A prototype web site and registry to make certificates generated by a CA publicly available: ranger6/xanna
A set of tools (mostly bash scripts) to standardize and simplify the publication of certificates, generate certificate bundles, etc.: ranger6/ca. This project includes an example workflow of setting up the CA with signing certificates, generating server certificates, publishing to a registry, and fetching certificates/bundles to provision servers. A good part of the workflow (the upstream part) is simply following Jamie’s tutorial.
Advise on all the provisioning gotcha’s are not covered. I mostly played around with Caddy (caddyserver.com).
Everything is free for the taking (MIT License). Comments and pull requests accepted!
First of all this is great article.
When I check certification path from browser, it is showing only intermediate certificate -> server certificate… why it is missing rootca… in certification path… I am expecting to show certification path as rootca-> intermediateca -> server.
A PDF version of https://jamielinux.com/docs/openssl-certificate-authority/index.html would be really handy to be stored together with produced files.
Is there any way to create certs with “Certificate transparency” using openssl CA ?
Hi, when I reached the “Create the intermediate certificate” step, while trying to sign the CSR with my root CA, I encountered this error message after keying my passphrase for my root CA private key,
ca: PKI/ca/root/newcerts is not a directory
PKI/ca/root/newcerts: No error
May I know what does this mean?
After much researching, I somehow believe this error is due to the fact that when I try to access my root ca configuration file, it is unable to read the respective directories under the [ CA_default ] section. This is because even the root private key and root certificate is listed under the [ CA_default] section, it will show an error message saying “unable to load CA private key” but after I indicated the path to the private key in my command line, this error message is gone. Therefore, I believe it is due to the file path naming convention but I still do not know under to resolve this. Please advise!
Below is the command I used:
C:\Users\QiKang.Lim\PKI\ca>openssl ca -config root\root.conf -keyfile root\private\ca.key.pem -cert root\certs\ca.cert.pem -extensions v3_intermediate_ca -days 3650 -notext -md sha256 -in intermediate\csr\intermediate.csr.pem -out intermediate\certs\intermediate.cert.pem
Hello Kyokku, i saw your post and i assume you are using windows to generate your own certificate authority and certificates. Do you encounter any problem accessing your root key and root configuration file when you are signing the CSR for your intermediate CA generation? I encounter some problems and hope you can advise me. Please and thank you!
Thank you very much for this guide on creating an OpenSSL CA. It’s extremely well written and I found it very helpful.
What a comprehensive, well-written, useful guide. This is really appreciated!
Thanks for the instructions but I’m running into a little bit of a problem with the following error:
Using configuration from intermediate/openssl.cnf Enter pass phrase for /root/ca/intermediate/private/intermediate.key.pem: 140423648978176:error:02001002:system library:fopen:No such file or directory:crypto/bio/bss_file.c:69:fopen('/root/ca/intermediate/index.txt','r') 140423648978176:error:2006D080:BIO routines:BIO_new_file:no such file:crypto/bio/bss_file.c:76:
This is occurring with the following command as listed in your guide:
# openssl ca -config intermediate/openssl.cnf \ -extensions server_cert -days 375 -notext -md sha256 \ -in intermediate/csr/www.example.com.csr.pem \ -out intermediate/certs/www.example.com.cert.pem
Found my own problem – no need to respond – I had a file called indext.txt rather than index.txt. I made the correction and things worked as expected. Thanks.
This is a create topic. I’m just curious about the configuration for ECC certificates, instead of RSA ones.
I can see the option default_md=256 and default_bits=4096, but for ECC certificates using prime256v1 algorithm this would be different, is that correct?
I have a question with regards to the use of ECC client certificates. Herein we create a rootCA and an intermediate CA. My question is “will the CSR for client will be valid irrespective of the type of algorithm used to generate the key?” In particular, in the post we use RSA algorithm for client key generation but the setup should work if we use say ECC keys?
BTW, Thanks for an amazing blog post.
@lacg, Did you get this working, if so would you like to share any pain points??
Hi, yes, I solved using default_md=sha384 (following this link).
I tried using sha512, but there was this comment on that page and although old, I couldn’t find anything saying that it was fixed.
" I am going to use secp384r1 as my curve of choice. It’s good to mention that RFC5480 notes secp256r1 (not listed) is referred to as prime256v1 for this output’s purpose. Why not use something larger than 384? Thank Google. People absolutely were using secp521r1 then Google dropped support for it (read Chromium Bug 478225 for more). The theory is since NSA Suite B PKI did not explicitly call out anything besides 256 or 384, the Chromium team quietly decided it wasn’t needed and dropped support for it. Yea… it kinda annoyed a few people. So to avoid future browser issues, we’re sticking with what’s defined in public standards."
Please, let me know if you have any problems.
I created some scripts for this that I could share and I could also share the cnf.
Good luck, Luiz