Firstly, it would be remiss to not state the obvious here:- in Domino 12 there is a complete overhaul of how you initiate certs and cert requests within Domino.
With the new CertMgr you can “magically” get a cert with LetsEncrypt. If you haven’t tried the beta of Domino 12 please do. It is magic.
Or if not a magic cert with Let’s Encrypt, a completely overhauled GUI if you want to be able to create certs with another third party CA (or even internal CA), or if you “just” want a wildcard cert.
However until Domino 12 comes out in production, I’m generally still using OpenSSL.
Recently a customer of ours had a requirement to turn on SSL on some of their internal web sites, with their own internal Certificate Authority.
We went through the standard procedure for this. I do several renewals of these a month, every month for customers usually for External CAs. It always works.
This time it worked for IE, but for Chrome and Edge, we got
What’s going on here? Well normally in OpenSSL we don’t explicitly set the “Subject Alternative Name” when generating the CSR. And by normally I mean I never had before. When we set the common name in the CSR the Certificate Authority (both external and internal) usually assumes this name from the common name and populates the Subject Alternative Name from that. Here the internal CA does not do this.
Ok, so I had to read into this a little. There is all sorts of “help” on the web on similar problems, most will lead you down very intricate dead ends with .cnf files, reading input from text files and all sorts of other headaches.
I’m here to make your life easier. If you get in this position. Don’t do any of that. Instead upgrade the version of OpenSSL to at least v. 1.1.1 then you can use a new switch, and create a CSR with the following syntax: (where the cert is a wildcard cert for *.example.local)
openssl req -new -sha256 -key server.key -addext “subjectAltName = DNS:*.example.local” -out server.csr
You can then verify that the CSR has explicitly added what you need with the following:-
openssl req -text -noout -verify -in server.csr
In the middle of the output it gives it will give you
Attributes:
Requested Extensions:
X509v3 Subject Alternative Name:
DNS:*.example.local
On the cert itself that’s generated this maps to a Subject Alternative Name populated with “DNS name=*.example.local”
From there follow the “usual” steps and you will no longer get either error in Chrome and Edge.
Hope you found this useful, it would have saved me a couple of hours had I known what to do!
Cormac McCarthy – Domino People Ltd
Alexandre says:
Hi!
Is “their own internal Certificate Authority” – CA’s task enabled Domino Internet Certifier?
How do you submit to Domino Internet CA (to CA process) your created CSR with SAN extension?
I have no idea, but only use of old certreq.nsf database (Submit, then Pull request from AdminP), but nothing happens with subjectAltNames, it disappears in the issued certificate…
Cormac McCarthy says:
Hi Alexandre,
It sounds like you’ve got some items mixed up there. Though I’m not actually 100 per cent sure I know what you’re asking. If you want to use an internal CA with Domino. Cert Manager is the easiest way of achieving this. That original post was pre – Domino 12 being released. This is the best way of achieving what you want – https://help.hcltechsw.com/domino/12.0.2/admin/secu_creating_micro_certificates.html
If you need further help email support@dominopeople.ie and we’ll see can we help.
Thanks,
Cormac
Alexandre says:
Hi Cormac,
Thanks a lot! MicroCA really seems like what I need.
Also I found this:
https://blog.nashcom.de/nashcomblog.nsf/dx/domino-v12-acme-for-company-cas-using-smallstep.htm
Alexandre