Private Key error

My domains are: sabots-libres.eu, sabotslibres.eu, sabotslibres.fr

I ran this command:

sudo certbot certonly -–manual -–force-renewal -d *.sabots-libres.eu,sabots-libres.eu,*.sabotslibres.eu,sabotslibres.eu,*.sabotslibres.fr,sabotslibres.fr

It produced this output: standard creation of _acme-challenge entries for the three domains and three files for the _well-known/acme-challenge directory on the web server

My web server is (include version): (not applicable)

The operating system my web server runs on is (include version): not applicable

I am running a standalone openSUSE Tumbleweed server to generate keys since I do not have shell access to the provider's web server.

My hosting provider, if applicable, is: n/a

I can login to a root shell on my machine (yes or no, or I don't know): yes, on my certificate machine.

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): yes, Direct Admin

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): 2.5.0

Previous generation of certificates have passed without incident. At the beginning of this year, I reinstalled the keyserver onto a Tumbleweed server after using Ubuntu for some while.
The generation of keys worked perfectly (two sites, four domains) in January.
Now I have attempted to regenerate for the second time for three of the four domains (which run on one single website).
Certbot generated the normal three-part fullchain.pem key but on opening the privkey.pem file, it was only 241 bytes whereas previously, it was 1704.
Similar to the problem mentioned in Issue SSL certificate successfully but found the content of privkey.pem is too short , the private key is a mere three lines long.
A second attempt to regenerate the keys resulted in exactly the same problem.
Any suggestions?

Since version 2.0.0 Certbot uses ECDSA keypairs by default. This should not affect existing certificates except for a bug where Certbot didn't register the RSA details in the renewal configuration file (Certbot before version 1.25.0).

So depending on your situation you might be able to continu using the ECDSA key(s) or revert back to RSA using the --key-type option for Certbot.

Also note that --force-renewal doesn't make much sense if you don't actually change anything from the existing certificate: you just get more and more of the same. Please don't use it unless absolutely necessary and you know what you're actually doing. Also note that it seems to be necessary to change the key type for an existing certificate which is not due for renewal yet. See User Guide — Certbot 2.5.0 documentation for more info.

7 Likes

Many thanks for the rapid reaction. It was indeed the RSA key. Strange because I believe the certificate issue I made in January was also post v2.0 and passed without problem.
--force-renewal was implemented simply because that was the documentation I had read - even now, it says in the certbot manual that it should be used for renewals ahead of the renewal date...

1 Like

That's correct, but without --key-type, renewing ahead of the renewal date didn't do anything good as far as I can tell :slight_smile:

4 Likes

Noted - thanks again. (Just done the second site without any hitch :grin: )

3 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.