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.
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!
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:
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.
And there’s no way to export the private key