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.
It produced this output:
nginx restart failed:
nginx: [emerg] SSL_CTX_use_certificate("/etc/letsencrypt/live/hemisfero.com-0001/fullchain.pem") failed (SSL: error:0A00018F:SSL routines::ee key too small)
My web server is (include version): NGINX 1.20.1
The operating system my web server runs on is (include version): RHEL 9.1
My hosting provider, if applicable, is: Linode
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): 1.32.1
Brand new server, only has NGINX installed. Did do a public/private key generation procedure prior using ssh keygen - set to 4096
I only brought up the private/public keys I generated for SSH use as they are the only keys on a brand new machine. I do not know how they would affect Certbot but they ARE 4096 bit.
Example:
[root@Hem01prod /]# cd home/Bob/.ssh
[root@Hem01prod .ssh]# ls
authorized_keys id_rsa id_rsa.pub
[root@Hem01prod .ssh]#
....there are two sets, one for each of the two non-root users.
...the darn server is brand-new, nothing has run on it as yet. MANY, many thanks for replying so fast. Only one or two mentions on internet of this type of message. None applicable.
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Renewal configuration file /etc/letsencrypt/renewal/hemisfero.com.conf produced an unexpected error: expected /etc/letsencrypt/live/hemisfero.com/cert.pem to be a symlink. Skipping.
[root@Hem01prod nginx]# ls -l /etc/letsencrypt/archive/hemisfero.com-0001/*
-rw-r--r--. 1 root root 1895 Dec 13 13:14 /etc/letsencrypt/archive/hemisfero.com-0001/cert1.pem
-rw-r--r--. 1 root root 1891 Dec 13 14:09 /etc/letsencrypt/archive/hemisfero.com-0001/cert2.pem
-rw-r--r--. 1 root root 3749 Dec 13 13:14 /etc/letsencrypt/archive/hemisfero.com-0001/chain1.pem
-rw-r--r--. 1 root root 3749 Dec 13 14:09 /etc/letsencrypt/archive/hemisfero.com-0001/chain2.pem
-rw-r--r--. 1 root root 5644 Dec 13 13:14 /etc/letsencrypt/archive/hemisfero.com-0001/fullchain1.pem
-rw-r--r--. 1 root root 5640 Dec 13 14:09 /etc/letsencrypt/archive/hemisfero.com-0001/fullchain2.pem
-rw-------. 1 root root 1704 Dec 13 13:14 /etc/letsencrypt/archive/hemisfero.com-0001/privkey1.pem
-rw-------. 1 root root 1704 Dec 13 14:09 /etc/letsencrypt/archive/hemisfero.com-0001/privkey2.pem
[root@Hem01prod nginx]# nginx -T | grep -i ssl
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
# listen 443 ssl http2;
# listen [::]:443 ssl http2;
# ssl_certificate "/etc/pki/nginx/server.crt";
# ssl_certificate_key "/etc/pki/nginx/private/server.key";
# ssl_session_cache shared:SSL:1m;
# ssl_session_timeout 10m;
# ssl_ciphers PROFILE=SYSTEM;
# ssl_prefer_server_ciphers on;
As @orangepizza points out, if you keep your OpenSSL Security Level set to 3, then your server won't be able to communicate with probably more than half the internet.
This might be fine or might not be, I don't know. Up to you and your use case.
Even if you ask Certbot to generate a certificate with a larger key (for example, by using --rsa-key-size 4096, or by choosing an ECDSA P-384 key), your security still might not like the certificate, because the intermediate certificate that Let's Encrypt uses is only 2048-bits as well.
(One exception: if you get your Let's Encrypt account whitelisted to have its certificates issued from the E1 issuer and issue an ECDSA P-384 certificate then, that might work for you. But it still means your server won't be able to communicate with most websites).
I can not tell you how much the lucid replies both of you (...here's to you to Orangepizza!) have helped. I think, in our use case, we are going to have to abandon ''FUTURE'' mode for the nonce - or, until the rest of the web has caught up. It was the first time (...just as RHEL 9.0 and now 9.1 is new to us) we tried future mode and this is our first RHEL 9.x server. I think the correct answer for a web server for general use ... as in our case ... is to eschew FUTURE and go to LEGACY mode.
Again, many thanks for the rapid solution to this mysterious message.
FYI ...for others following. Changing to LEGACY mode allowed #certbot --nginx to correctly generate certificates and modify nginx configs. Domains now correctly served with "https:"
You have both IPv4 and IPv6 addresses in your DNS but IPv6 is not working. You can see this on the Let's Debug test site (link here).
The Let's Encrypt HTTP challenge will first use IPv6 but certain errors have it then try IPv4. That must be what happened to allow you to get certs.
Also, you have a www subdomain in DNS. An HTTP connection to it works but HTTPS connections fail because your cert does not include the www subdomain in it.
Quite! Luckily, we are just starting the process of setting the server up and we will be on to these helpful pointers and fix the issues, asap. Many thanks, Mike!!!
