I’ve generated a CSR on a IBM HMC that runs Apache. It contains the domain name in the CN but also includes the hostname (without the FQDN) in the subject alternative name section.
Subject: C=FR, L=[…], CN=hmc.domain.com
X509v3 Subject Alternative Name:
I get an error when I try to generate the signed certificate on a Redhat server:
letsencrypt --manual --csr csr.file -d hmc.domain.com certonly
No handlers could be found for logger "certbot.crypto_util"
Requested domain hmc is not a FQDN
I guess this comes from the alias name but I have no way to change it since it’s created on a very restrictive web interface with no access to the filesystem.
Is there a way to ignore aliases in the CSR? Or did I miss something obvious?
While this particular error is generated by the client, the CA server also performs that check on the SAN field and would trigger an error (“policy forbids issuing” or something like that) if you submit that CSR.
Is it possible to export the private key from that device? In that case, you’d be able to use that key to generate a valid CSR on a different device and use that. Other than that, I don’t think you’ll be able to get this to work.
Another possibility is that sometimes devices will let you import both a key AND an associated certificate together, for example in a file with the extension .PFX. In this case you could use certbot (or another Let’s Encrypt client) to make the key and certificate, do any format conversion needed then upload both to the HMC. But if this isn’t explicitly called out as a possibility in the interface or manual, it likely won’t work.
I tried to import a new private key and certificate but the system expects a certificate that matches the private key it previously generated And there’s no way to export the private key
Oh well, I’ll keep that self signed certificate issued by “null” causing me some trouble with most browsers, obviously!
Thanks for your suggestions
I managed to get the private key on the HMC, generate a new CSR and submit to Let’s Encrypt.
All worked perfectly but the expiration date: it’s valid till the 12/12/16
CSR was created like this:
openssl req -new -key pending.server.key -days 365 > csr.file
on a server that has the correct date:
Tue Sep 13 15:37:31 CEST 2016
I’m not sure wether it’s an OpenSSL or Let’s Encrypt’s issue.
I’m not sure what “issue” you are referring to here.
Let’s Encrypt issues certificates which are valid for 90 days ( it doesn’t matter what you put in your CSR file ). Obtaining a certificate valid until 12/12/16 seems perfectly right, and you have a valid cert.
Am I missing something ?
The “-days 365” is saved in the csr but is ignored by Let’s Encrypt.
Fair enough, I did not see that info
Thanks for your replies and keep up the good work!
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.