Issue SSL certificate successfully but found the content of privkey.pem is too short

Help
1

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: juve07.com

I ran this command:
certbot certonly --dns-cloudflare --dns-cloudflare-credentials /root/.ssh/cloudflare.ini -d juve07.com,*.juve07.com --preferred-challenges dns

It produced this output:
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Requesting a certificate for juve07.com and *.juve07.com

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/juve07.com/fullchain.pem
Key is saved at: /etc/letsencrypt/live/juve07.com/privkey.pem
This certificate expires on 2023-05-18.
These files will be updated when the certificate renews.
Certbot has set up a scheduled task to automatically renew this certificate in the background.

If you like Certbot, please consider supporting our work by:

My web server is (include version):
Linux version 3.10.0-1062.12.1.el7.x86_64 (mockbuild@kbuilder.bsys.centos.org) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-39) (GCC) ) #1 SMP Tue Feb 4 23:02:59 UTC 2020

The operating system my web server runs on is (include version):
Linux version 4.18.0-348.7.1.el8_5.x86_64 (mockbuild@kbuilder.bsys.centos.org) (gcc version 8.5.0 20210514 (Red Hat 8.5.0-4) (GCC)) #1 SMP Wed Dec 22 13:25:12 UTC 2021

My hosting provider, if applicable, is:

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

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

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

As the topic mentioned, I am still having this issue for two days.
Two days ago, I failed to restart nginx service after deployed the ssl certificate. Then I found out that the content of privkey.pem was not normal. There are only three lines in it. So no matter how many domains I tried to issue ssl certificates by certbot, the results were still the same. It doesn't like the normal one I used to issue. The content of abnormal privkey.pem is as below.

-----BEGIN PRIVATE KEY-----
[ ----- KEY REMOVED BY STAFF ---- ]
-----END PRIVATE KEY-----

I don't know whether anyone here had this issue before or not. Please help. Thanks.

2

I have removed the private key from your post before approving it.

Because you have leaked your private key, we are going to have to revoke the certificate(s) affected. It doesn't look quite right, though, as there was a * in it for example: Have you edited it at all before posting? From the logs you've posted it looks like the cert for juve07.com expiring on 2023-05-18. Can you confirm that's the private key you posted?

Certbot 2.x defaults to ECDSA keys, which are three lines of text, so that seems normal. Perhaps the software you're using, which you haven't specified, doesn't support ECDSA, or isn't configured to understand it properly. You can use the --key-type rsa flag to request an RSA key, which are larger and were the default in Certbot 1.x: User Guide — Certbot 2.3.0 documentation

4 Likes
3

Yes, I had edited it before posting just in case the leaking you mentioned.
What software do you mean?
Maybe I had updated certbot recently and didn't notice the change of keys.
In this case, I will look into how to change the configuration of the nginx.

4

Can you please revoke your certificate like this first, just to be safe, even if you did change the private key:
certbot revoke --cert-name juve07.com --reason keycompromise

You can try adding the --key-type rsa argument like this and see if it works better with nginx:

certbot certonly --key-type rsa --dns-cloudflare --dns-cloudflare-credentials /root/.ssh/cloudflare.ini -d juve07.com,*.juve07.com --preferred-challenges dns

What error do you get from nginx when it fails to restart? What version of nginx are you running?

2 Likes
5

I'm using nginx/1.14.1
The error is as below

Feb 17 12:37:33 ip-172-24-1-14.ap-east-1.compute.internal systemd[1]: nginx.service: Succeeded.
Feb 17 12:37:33 ip-172-24-1-14.ap-east-1.compute.internal systemd[1]: Stopped The nginx HTTP and reverse proxy server.
Feb 17 12:37:33 ip-172-24-1-14.ap-east-1.compute.internal systemd[1]: Starting The nginx HTTP and reverse proxy server...
Feb 17 12:37:33 ip-172-24-1-14.ap-east-1.compute.internal nginx[134500]: nginx: [warn] conflicting server name "multistaging.bluebirds.cc" on 0.0.0.0:80, ignored
Feb 17 12:37:33 ip-172-24-1-14.ap-east-1.compute.internal nginx[134500]: nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
Feb 17 12:37:33 ip-172-24-1-14.ap-east-1.compute.internal nginx[134500]: nginx: [emerg] zero size shared memory zone "server"
Feb 17 12:37:33 ip-172-24-1-14.ap-east-1.compute.internal nginx[134500]: nginx: configuration file /etc/nginx/nginx.conf test failed
Feb 17 12:37:33 ip-172-24-1-14.ap-east-1.compute.internal systemd[1]: nginx.service: Control process exited, code=exited status=1
Feb 17 12:37:33 ip-172-24-1-14.ap-east-1.compute.internal systemd[1]: nginx.service: Failed with result 'exit-code'.
Feb 17 12:37:33 ip-172-24-1-14.ap-east-1.compute.internal systemd[1]: Failed to start The nginx HTTP and reverse proxy server.

But it restarted successfully after I removed listen 443 ssl and the ssl certificate path from the conf file.

6

ECDSA is not abnormal and nginx should be able to handle that perfectly :slight_smile:

I'm not familiar with this error, but I'm not sure it has anything to do with the certificate/private key.

5 Likes
8

Thanks, guys.
I had solved the issue by adding these two lines.

	limit_req_zone $binary_remote_addr zone=flood:50m rate=90r/s;
	limit_conn_zone $binary_remote_addr zone=addr:50m;

Now my web server is able to use ECSDA certificate.

1 Like
9

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