I have two raspberry pi servers running. These were set up with DietPi. The one server is used as a NextCloud server. The other (new) server is running weewx. Both use lighttpd as the webserver. Each operates under a different domain my.domain.com and my.otherdomain.com. My router has a single IP address and I use port forwarding to access both servers. The NextCloud server (my.domain.com) has SSL enabled using dietpi-letsencrypt. I cannot run certbot on my.otherdomain.com because I only have one public IP address. I enabled mod-proxy on my Nextcloud machine (my.domain.com) and it forwards requests to my.otherdomain.com to the weewx machine. I disabled port forwarding on the router to the weewx machine. However, dietpi-letsencrypt cannot generate a SSL certificate for the weewx machine - the challenges fail. I tried to run certbot on both machines. Here is the attempt for my Nextcloud machine (used as my proxy server):

Do you want to expand and replace this existing certificate with the new
certificate?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(E)xpand/(C)ancel: E 
Renewing an existing certificate for my.domain.com and my.otherdomain.com
Performing the following challenges:
http-01 challenge for aws.andrewterhorst.com
Using the webroot path /var/www for all unmatched domains.
Waiting for verification...
Challenge failed for domain my.otherdomain.com
http-01 challenge for my.otherdomain.com
Cleaning up challenges
Some challenges have failed.

IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: my.otherdomain.com
   Type:   unauthorized
   Detail: Invalid response from
   http://my.otherdomain.com/.well-known/acme-challenge/p16SmhyufIGQ75fnhWQ4zxf49TCLfnX4SoWRmBqAHBg 

server.feature-flags       += ("server.h2c"     => "enable")
server.feature-flags       += ("server.graceful-shutdown-timeout" => 5)
#server.feature-flags       += ("server.graceful-restart-bg" => "enable")

# strict parsing and normalization of URL for consistency and security
# https://redmine.lighttpd.net/projects/lighttpd/wiki/Server_http-parseoptsDetails 
# (might need to explicitly set "url-path-2f-decode" = "disable"
#  if a specific application is encoding URLs inside url-path)
server.http-parseopts = (
  "header-strict"           => "enable",# default
  "host-strict"             => "enable",# default
  "host-normalize"          => "enable",# default
  "url-normalize-unreserved"=> "enable",# recommended highly
  "url-normalize-required"  => "enable",# recommended
  "url-ctrls-reject"        => "enable",# recommended
  "url-path-2f-decode"      => "enable",# recommended highly (unless breaks app)
 #"url-path-2f-reject"      => "enable",
  "url-path-dotseg-remove"  => "enable",# recommended highly (unless breaks app)
 #"url-path-dotseg-reject"  => "enable",
 #"url-query-20-plus"       => "enable",# consistency in query string
)

index-file.names            = ( "index.php", "index.html" )
url.access-deny             = ( "~", ".inc" )
static-file.exclude-extensions = ( ".php", ".pl", ".fcgi" )

# default listening port for IPv6 falls back to the IPv4 port
include_shell "/usr/share/lighttpd/use-ipv6.pl " + server.port
include_shell "/usr/share/lighttpd/create-mime.conf.pl"
include "/etc/lighttpd/conf-enabled/*.conf"

#server.compat-module-load   = "disable"
server.modules += (
	"mod_dirlisting",
	"mod_staticfile",
)


# proxy settings
$HTTP["host"]=~ "my.otherdomain.com"  {
        proxy.balance = "fair"
        proxy.server =  ("" =>
                                (
                                        ( "host" => "192.168.0.261", "port" => 80 ),
                                        ( "host" => "192.168.0.261", "port" => 443 )
                                ))
                        }

Technically, the proxy settings should be in 10-proxy.conf. I need to run this command:

lighty-enable-mod proxy

This creates a symbolic link in /etc/lighttpd/conf-enabled to 10-proxy.conf in /etc/lighttpd/conf-available. I read I could simply add proxy settings in lighttpd.conf - it was not necessary to use 10-proxy.conf. The current set-up means incoming traffic to my.otherdomain.com ends up on the second weewx machine. However, certbot needs to communicate out. I am confused about where I should run certbot - from my weewx machine or from my NextCloud machine? I am not a Linux boffin and need some guidance on how to set up lighttpd to do forward and reverse proxies so my weewx machine can be secure. Most of the posts touching on this refer to Apache, nginx, or some specific web application setup. The syntax of the lighttpd conf settings is rather confusing using regex like notation. For example:

$HTTP['host'] =~ '^(www.example.com)$' {
        url.rewrite-once = ('^/(.*)' => '/vhost/http/%0/$1')
        # In lighttpd we alter the path manually using rewrite rule. %0
        # refers to the hostname and $1 is the path.
        proxy.server = ( '' =>
                ( (
                'host' => '127.0.0.1',
                'port' => 8080
                ) )
        )
}

There is no step by step tutorial in plain simple English for simpletons such as me.

How do I manually update the certificates that Certbot would normally update? I did not change anything in my system so I am assuming it is because I have CentOS 6. I also have Apache. How do I update the certificates manually? SUBJECT: Cron scl enable python27 "/root/certbot-auto renew --quiet" Your system is not supported by certbot-auto anymore. Certbot will no longer receive updates. Please visit https://certbot.eff.org/ to check for other alternatives.

I see my webpage as secure in my browser but other people don't see it that way? I'm using certbot on a LAMP stack on Ubuntu 20.04 csyyc.ca Yeah… someone downvoted my answer, pretty sure the reason i had split results is because of the www subdomain i assume they’ve used. Thanks a lot guys and gj

Is there a way to use certbot and letsencrypt certificate for multiserver setup without having to manually copy the certificates from one node to another? I have a domain name example.com which is resolved to 192.0.2.1 in Americas and to 192.0.2.2 in Asia. I run certbot from American server and it successfully generates certificate. I can't run the same command from Asian server, as certbot will be able to resolve domain only to 192.0.2.1. Therefore in order to install certificate for Asian server I have to copy it from 192.0.2.1 to 192.0.2.2. Yes, the copy process can be scripted, though it doesn't look like a good idea for me. Is there other way around?

I have certbot installed and successfully use it to encrypt my homepage. Now I tried to set up an email system for my website using dovecot and postfix. I got it mostly running; the only problem is that thunderbird gives me a warning about the address being fraudulent because I use the SSL key of mysite.com for imap.mysite.com (same for SMTP). How can I add imap.mysite.com and smtp.mysite.com to the existing mysite.com certificate using certbot in order to avoid the warning?

Good day, I'm having a problem renewing a domain with certbot. This is the error I'm getting: root@mywebserver:~# certbot renew Saving debug log to /var/log/letsencrypt/letsencrypt.log - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Processing /etc/letsencrypt/renewal/mywebsite.com.conf - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Renewing an existing certificate for mywebsite.com and www.mywebsite.com Failed to renew certificate mywebsite.com with error: Could not bind TCP port 80 because it is already in use by another process on this system (such as a web server). Please stop the program in question and then try again. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - All renewals failed. The following certificates could not be renewed: /etc/letsencrypt/live/mywebserver.com/fullchain.pem (failure) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1 renew failure(s), 0 parse failure(s) Currently, I'm running a Wordpress instance with OpenLiteSpeed WordPress One-Click app, which is supposed to automatically renew certs for me, but it hasn't been the case. The image comes with automatic certificate renewal by default in /etc/cron.d/certbot: SHELL=/bin/sh PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin 0 */12 * * * root test -x /usr/bin/certbot -a \! -d /run/systemd/system && perl -e 'sleep int(rand(43200))' && certbot -q renew --deploy-hook "systemctl restart lsws" 0 0 * * 3 root systemctl restart lsws I mean, sure, I can go and stop my webserver and proceed with certbot renew process, but then I wont be able to fix this and go through all this again once the certificate ends again. Huge thanks in advance to anyone who jumps in to help me with this.

I believe the two issues I'm having are related, but don't know where to begin. The first issue is that when a specific domain that resolves to my server is requested, its conf file in sites-enabled is ignored, as is 000-default.conf, instead the first conf next in alphabetical order is used and that site appears, but with the domain I requested in the browser bar. This only happens with this one domain, which leads to the second problem. I have a multi-domain cert (CA) and all the domains in it show up as expected. I have an installed certbot cert for this other domain. When I use openssl with the domain name of this other domain, it shows the contents of the multi-domain cert. When I use an SSL checker I get the same results, with it noting that the domain name I entered is not included in the cert. I notice that when I do apachectl -S prior to listing the *:443 and *:80 files it lists a virtual host with the server's IP address as the named server, and the first file it lists is not the 000-default (which IS listed as the first for *:80 and *:443) but the next one alphabetically. THe problematic domain is halgrossman.com. **halgrossman.com.conf** ServerName halgrossman.com ServerAlias www.halgrossman.com ServerAdmin webmaster@localhost DocumentRoot /var/www/html/drupal/halgrossman/web Options Indexes FollowSymLinks MultiViews AllowOverride All Order allow,deny allow from all ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined **halgrossman.com-le-ssl.conf** ServerName halgrossman.com ServerAlias www.halgrossman.com ServerAdmin webmaster@localhost DocumentRoot /var/www/html/drupal/halgrossman/web Options Indexes FollowSymLinks MultiViews AllowOverride All Order allow,deny allow from all ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined Include /etc/letsencrypt/options-ssl-apache.conf SSLCertificateFile /etc/letsencrypt/live/halgrossman.com/fullchain.pem SSLCertificateKeyFile /etc/letsencrypt/live/halgrossman.com/privkey.pem **Output from openssl** openssl s_client -connect halgrossman.com:443 -servername halgrossman.com CONNECTED(00000003) depth=2 C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority verify return:1 depth=1 C = GB, ST = Greater Manchester, L = Salford, O = Sectigo Limited, CN = Sectigo RSA Domain Validation Secure Server CA verify return:1 depth=0 CN = theaccidentalcoder.com verify return:1 --- Certificate chain 0 s:CN = theaccidentalcoder.com i:C = GB, ST = Greater Manchester, L = Salford, O = Sectigo Limited, CN = Sectigo RSA Domain Validation Secure Server CA a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256 v:NotBefore: Sep 2 00:00:00 2024 GMT; NotAfter: Dec 21 23:59:59 2024 GMT 1 s:C = GB, ST = Greater Manchester, L = Salford, O = Sectigo Limited, CN = Sectigo RSA Domain Validation Secure Server CA i:C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA384 v:NotBefore: Nov 2 00:00:00 2018 GMT; NotAfter: Dec 31 23:59:59 2030 GMT 2 s:C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority i:C = GB, ST = Greater Manchester, L = Salford, O = Comodo CA Limited, CN = AAA Certificate Services a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA384 v:NotBefore: Mar 12 00:00:00 2019 GMT; NotAfter: Dec 31 23:59:59 2028 GMT 3 s:C = GB, ST = Greater Manchester, L = Salford, O = Comodo CA Limited, CN = AAA Certificate Services i:C = GB, ST = Greater Manchester, L = Salford, O = Comodo CA Limited, CN = AAA Certificate Services a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA1 v:NotBefore: Jan 1 00:00:00 2004 GMT; NotAfter: Dec 31 23:59:59 2028 GMT theaccidentalcoder.com is the primary domain on a multi domain CA cert, which halgrossman.com is **not** part of. **Output from SSL Checker** halgrossman.com resolves to 45.56.118.187 Server Type: Apache/2.4.52 (Ubuntu) The certificate should be trusted by all major web browsers (all the correct intermediate certificates are installed). The certificate was issued by Sectigo. The certificate will expire in 84 days. None of the common names in the certificate match the name that was entered (halgrossman.com). You may receive an error when accessing this site in a web browser. Learn more about name mismatch errors. Common name: theaccidentalcoder.com SANs: theaccidentalcoder.com, ascaatl.org, guildbuildersinc.com, musictohealby.com, souknook.com, thetouristlife.com Valid from September 1, 2024 to December 21, 2024 **Output from apache2ctl -S** 45.56.118.187:443 is a NameVirtualHost default server guildbuildersinc.com (/etc/apache2/sites-enabled/guildbuildersinc.com.conf:37) port 443 namevhost guildbuildersinc.com (/etc/apache2/sites-enabled/guildbuildersinc.com.conf:37) port 443 namevhost musictohealby.com (/etc/apache2/sites-enabled/musictohealby.com.conf:37) port 443 namevhost theaccidentalcoder.com (/etc/apache2/sites-enabled/theaccidentalcoder.com.conf:23) port 443 namevhost thetouristlife.com (/etc/apache2/sites-enabled/thetouristlife.com.conf:21) *:443 halgrossman.com (/etc/apache2/sites-enabled/halgrossman.com-le-ssl.conf:2) *:80 is a NameVirtualHost default server halgrossman.com (/etc/apache2/sites-enabled/00-default.conf:1) port 80 namevhost halgrossman.com (/etc/apache2/sites-enabled/00-default.conf:1) alias www.halgrossman.com port 80 namevhost default (/etc/apache2/sites-enabled/000-default.conf:1) port 80 namevhost guildbuildersinc.com (/etc/apache2/sites-enabled/guildbuildersinc.com.conf:1) alias www.guildbuildersinc.com port 80 namevhost halgrossman.com (/etc/apache2/sites-enabled/halgrossman.com.conf:1) alias www.halgrossman.com port 80 namevhost musictohealby.com (/etc/apache2/sites-enabled/musictohealby.com.conf:1) alias www.musictohealby.com port 80 namevhost theaccidentalcoder.com (/etc/apache2/sites-enabled/theaccidentalcoder.com.conf:1) alias www.theaccidentalcoder.com port 80 namevhost thetouristlife.com (/etc/apache2/sites-enabled/thetouristlife.com.conf:1) ServerRoot: "/etc/apache2" Main DocumentRoot: "/var/www/html" Note that the domain list appearing first is listed for the IP, and does not include 000-default. The one it ** does ** list first, guildbuildersinc.com, is the first, alphabetically, after 000-default, and the site that appears when requesting https://halgrossman.com .

I enabled both 80 and 443. sudo certbot certonly --standalone --agree-tos --no-eff-email --staple-ocsp --preferred-challenges http -m **@**.com -d mycomp.com Saving debug log to /var/log/letsencrypt/letsencrypt.log Requesting a certificate for mycomp.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Could not bind TCP port 80 because it is already in use by another process on this system (such as a web server). Please stop the program in question and then try again. Let's Debug shows ANotWorking ERROR mycomp.com has an A (IPv4) record (*.***.***.***) but a request to this address over port 80 did not succeed. Your web server must have at least one working IPv4 or IPv6 address. I do not understand what is wrong with port 80. How to fix this?

I'm doing the Let’s Encrypt *for the firs time* and this *101 question* might quite possibly have been answered somewhere, but anyway, from https://eff-certbot.readthedocs.io/en/latest/using.html#setting-up-automated-renewal > Most Certbot installations come with automatic renewals preconfigured. This is done by means of a scheduled task which runs certbot renew periodically. So, to simplify things, I'm using the Certbot docker container to get certificate, and that container does not come with automatic renewals preconfigured, thus I need to enable that functionality myself. The scheduled cron task is pretty straightforward: 0 0,12 * * * root sleep $SLEEPTIME && certbot renew -q My question is, Let's Encrypt certificates is good for **three months**, but this official recommendation from the Certbot document says that we need to try renewal **every 12 hours**. This looks really excessive to me. Anyone know how soon we can do the renewal? (As from https://unix.stackexchange.com/questions/760300/update-lets-encrypt-certificate-from-command-line I know that there is no --force-renewal option) I meant, if the renewal can happen 10 days ahead, then my cron job can be set every 5 days, if 6 days ahead, I'll use 3. Also anyone knows if certbot renew's return code can be used to notify my script to trigger my nginx config reload after the renewal indeed happens? Thanks

I am following this guide on how to Configure SSL/TLS on Amazon Linux 2023 . It recommends to obtain a CA-signed certificate using Certbot . And to get Certbot, it's recommended to install Snap. I have tried several things, not able to install any of prerequisites: sudo yum install snapd Error: Unable to find a match: snapd sudo amazon-linux-extras install epel sudo: amazon-linux-extras: command not found sudo yum install -y amazon-linux-extras Error: Unable to find a match: amazon-linux-extras

I'm enabling Gitea HTTPS access . On my server I got certificates using Certbot . The certificates are installed into: Certificate Path: /etc/letsencrypt/live/mydomain/fullchain.pem Private Key Path: /etc/letsencrypt/live/mydomain/privkey.pem and here their default permissions: $ ls -lh /etc/letsencrypt/live/mydomain/*.pem lrwxrwxrwx 1 root root 36 May 5 11:34 /etc/letsencrypt/live/mydomain/cert.pem -> ../../archive/mydomain/cert1.pem lrwxrwxrwx 1 root root 37 May 5 11:34 /etc/letsencrypt/live/mydomain/chain.pem -> ../../archive/mydomain/chain1.pem lrwxrwxrwx 1 root root 41 May 5 11:34 /etc/letsencrypt/live/mydomain/fullchain.pem -> ../../archive/mydomain/fullchain1.pem lrwxrwxrwx 1 root root 39 May 5 11:34 /etc/letsencrypt/live/mydomain/privkey.pem -> ../../archive/mydomain/privkey1.pem here the actual files: $ ls -lh /etc/letsencrypt/archive/mydomain/*.pem -rw-r--r-- 1 root root 1.5K May 5 11:34 /etc/letsencrypt/archive/mydomain/cert1.pem -rw-r--r-- 1 root root 1.8K May 5 11:34 /etc/letsencrypt/archive/mydomain/chain1.pem -rw-r--r-- 1 root root 3.3K May 5 11:34 /etc/letsencrypt/archive/mydomain/fullchain1.pem -rw------- 1 root root 241 May 5 11:34 /etc/letsencrypt/archive/mydomain/privkey1.pem $ ls -lh /etc/letsencrypt/archive/ total 4.0K drwxr-xr-x 2 root root 4.0K May 5 11:34 mydomain $ ls -lh /etc/letsencrypt/ total 28K drwx------ 3 root root 4.0K May 5 11:11 accounts drwx------ 3 root root 4.0K May 5 11:34 archive drwx------ 3 root root 4.0K May 5 11:34 live -rw-r--r-- 1 root root 774 May 5 11:11 options-ssl-nginx.conf drwxr-xr-x 2 root root 4.0K May 5 11:34 renewal drwxr-xr-x 5 root root 4.0K May 5 11:11 renewal-hooks -rw-r--r-- 1 root root 424 May 5 11:11 ssl-dhparams.pem They seem all readable from other users, even the parent directories until live that is readable only by root. When I run Gitea service I get the following error: May 05 11:47:53 vps gitea: 2024/05/05 11:47:53 cmd/web_https.go:170:runHTTPS() [E] Failed to load https cert file /etc/letsencrypt/live/mydomain/fullchain.pem for tcp:0.0.0> May 05 11:47:53 vps gitea: 2024/05/05 11:47:53 cmd/web.go:353:listen() [E] Failed to start server: open /etc/letsencrypt/live/mydomain/fullchain.pem: permission denied Gitea has its own user gitea. How to allow it to read the certificates? I'm concerned of just making the directory 755.

I followed [Cerbot's instructions](https://certbot.eff.org/instructions?ws=nginx&os=debianbuster) to get a HTTPS certificate for NGINX in my Debian server for a domain, but the HTTPS is not redirecting properly. I got the following in etc/nginx/conf.d/app.conf from Certbot's automatic generation:

server {
    server_name mnpd.khkm.dev www.mnpd.khkm.dev;
    # listen 8080;
    server_tokens off;
    location /.well-known/acme-challenge/ {
        root /var/www/certbot;
    }
    location / {
    	# return 301 https://mnpd.khkm.dev$request_uri ;
    	proxy_pass http://mnpd.khkm.dev ;
    }

    listen [::]:443 ssl ipv6only=on; # managed by Certbot
    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/mnpd.khkm.dev/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/mnpd.khkm.dev/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

}
server {
    if ($host = mnpd.khkm.dev) {
        return 301 https://$host$request_uri ;
    } # managed by Certbot


    listen 80;
    listen [::]:80;
    server_name mnpd.khkm.dev www.mnpd.khkm.dev;
    return 404; # managed by Certbot
}

In Chrome, when I go to [https://mnpd.khkm.dev/](https://mnpd.khkm.dev/) , I get:

page isn’t working.
mnpd.khkm.dev redirected you too many times.
Try deleting your cookies.
ERR_TOO_MANY_REDIRECTS

I found this [Stack Overflow answer](https://stackoverflow.com/a/51715058/8811872) where I looked at the "Network" tab in the web console and saw that the page is constantly being redirected to https://mnpd.khkm.dev/ . The NGINX configuration should be listening to port 443 for the HTTPS, so why isn't it loading and constantly being redirected? (I expect the default NGINX page to be loaded.)

I generated a certificate file with certbot. It is placed in /etc/letsencrypt/.... I created a group called elk where I added the elasticsearch user, and I recursively set it as the owning group for /etc/letsencrypt and recursively set the permissions to 770. When I start elasticsearch via systemctl start elasticsearch.service, it is not able to read the file? `Caused by: java.security.AccessControlException: access denied ("java.io.FilePermission" "/etc/letsencrypt/live//fullchain.pem" "read") ` Why is that? What strategy would you recommend to be able to use the same certificate for elasticsearch and kibana?

On Centos Stream 9, when I try to install certbot (sudo yum install certbot) into the server it returns:

Error: 
 Problem: package certbot-1.22.0-1.el8.noarch requires python3-certbot = 1.22.0-1.el8, but none of the providers can be installed
  - conflicting requests
  - nothing provides python3.6dist(setuptools) >= 39.0.1 needed by python3-certbot-1.22.0-1.el8.noarch
  - nothing provides python3.6dist(cryptography) >= 2.5.0 needed by python3-certbot-1.22.0-1.el8.noarch
  - nothing provides python3.6dist(configobj) >= 5.0.6 needed by python3-certbot-1.22.0-1.el8.noarch
  - nothing provides python3.6dist(distro) >= 1.0.1 needed by python3-certbot-1.22.0-1.el8.noarch
  - nothing provides /usr/bin/python3.6 needed by python3-certbot-1.22.0-1.el8.noarch
  - nothing provides python3.6dist(pytz) needed by python3-certbot-1.22.0-1.el8.noarch
  - nothing provides python(abi) = 3.6 needed by python3-certbot-1.22.0-1.el8.noarch
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)

I've tried to install python3-certbot from the official site but also returned this error. Also, I tried to set PowerTools on but seems like the repo didn't exist so I couldn't. Is there a way that I can install certbot?

I have a small test server at home and I registered with letsencrypt to get a valid certificate. Certificate expired and wasn't automatically renewed (no harm done, this is strictly for testing purposes). I don't remember exactly how I installed the certificate and "certbot" was not installed on my server (actually a LXD container, if relevant) running "Debian GNU/Linux 12 (bookworm)". I installed certbot with standard:

sudo apt update && sudo apt install certbot python3-certbot-nginx

and then proceeded to use it:

sudo certbot --nginx -d blog.mydomain.it

but I got an unexpected error:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Requesting a certificate for blog.mydomain.it

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/blog.mydomain.it/fullchain.pem
Key is saved at:         /etc/letsencrypt/live/blog.mydomain.it/privkey.pem
This certificate expires on 2024-02-14.
These files will be updated when the certificate renews.
Certbot has set up a scheduled task to automatically renew this certificate in the background.

Deploying certificate
Successfully deployed certificate for blog.mydomain.it to /etc/nginx/sites-enabled/blog.conf
We were unable to install your certificate, however, we successfully restored your server to its prior configuration.

NEXT STEPS:
- The certificate was saved, but could not be installed (installer: nginx). After fixing the error shown below, try installing it again by running:
  certbot install --cert-name blog.mydomain.it

nginx restart failed:
2023/11/16 23:31:55 [emerg] 561#561: SSL_CTX_use_PrivateKey("/etc/letsencrypt/blog.mydomain.it_ecc/private.key") failed (SSL: error:05800074:x509 certificate routines::key values mismatch)

Ask for help or search for solutions at https://community.letsencrypt.org . See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.

I guess there's some mismatch between previous certificate install and what certbot is trying to do, but I am at a loss about how to proceed. I have no problem in wiping the old certificate, if that's useful, but I would like to understand before I make a deeper mess. I need to reinstall certificates without disturbing the server itself (reasonable downtime is perfectly OK). UPDATE: - As requested (it doesn't seem to add any info, but...):

mcon@webserver:~$ sudo certbot install --cert-name blog.mydomain.it
[sudo] password for mcon: 
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Deploying certificate
Successfully deployed certificate for blog.mydomain.it to /etc/nginx/sites-enabled/blog.conf
We were unable to install your certificate, however, we successfully restored your server to its prior configuration.
nginx restart failed:
2023/11/17 09:08:38 [emerg] 3162#3162: SSL_CTX_use_PrivateKey("/etc/letsencrypt/blog.mydomain.it_ecc/private.key") failed (SSL: error:05800074:x509 certificate routines::key values mismatch)

Ask for help or search for solutions at https://community.letsencrypt.org . See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.
mcon@webserver:~$

UPDATE2: - my /etc/nginx/sites-enabled/blog.conf contained the following definition:

server {
    listen 443 ssl;
    server_name blog.mydomain.it;
    root /var/www/vitepress;
    ssl_certificate /etc/letsencrypt/blog.mydomain.it/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/blog.mydomain.it/privkey.pem;
    ssl_certificate /etc/letsencrypt/blog.mydomain.it/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/blog.mydomain.it_ecc/private.key;

    location / {
        index index.html;
        try_files $uri $uri/ /index.html;
    }
}

commenting out the second ssl_certificate/ssl_certificate_key pair actually solves the problem. Now my my (working!) installation reads:

server {
    listen 443 ssl;
    server_name blog.mydomain.it;
    root /var/www/vitepress;
    ssl_certificate /etc/letsencrypt/live/blog.mydomain.it/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/blog.mydomain.it/privkey.pem; # managed by Certbot

    location / {
        index index.html;
        try_files $uri $uri/ /index.html;
    }
}
server {
    if ($host = blog.mydomain.it) {
        return 301 https://$host$request_uri ;
    } # managed by Certbot

    listen 80;
    server_name blog.mydomain.it;
    return 404; # managed by Certbot
}

I am still curious about what was actually wrong and why those two lines were there (to avoid repeating the mistake, of course) but problem seems resolved.

I want to expand an existing file instead of creating a new certificate for a subdomain. I have these domains already in the file:

certtool -i < /etc/letsencrypt/live/example.org-0002/fullchain.pem|grep DNSname
                        DNSname: forum.example.com
                        DNSname: m.example.de
                        DNSname: m.example.org
                        DNSname: example.com
                        DNSname: example.de
                        DNSname: example.org
                        DNSname: wiki.example.org
                        DNSname: www.example.com
                        DNSname: www.example.de
                        DNSname: www.example.org

(certtool is part of the package gnutls-bin in debian) I know, there is the certbot --expand option, but if I don't get the exact set of domains again, it will create a new certificate with the next suffix -0003 How can I prevent that, if I only want to add one domain to an existing cert file?

Zimbra Certbot LetsEncrypt I have installed a LetsEncrypt SSL certificate on a separate server for a different domain without problems. I followed the same procedures that I used on that server for a new server (Ubuntu Server - same as the other) and everything worked up until the verification.

** Verifying '/opt/zimbra/ssl/letsencrypt/cert.pem' against '/opt/zimbra/ssl/zimbra/commercial/commercial.key'

140072965674304:error:0607907F:digital envelope routines:EVP_PKEY_get0_RSA:expecting an rsa key:crypto/evp/p_lib.c:474:

ERROR: Certificate '/opt/zimbra/ssl/letsencrypt/cert.pem' and private key '/opt/zimbra/ssl/zimbra/commercial/commercial.key' do not match.

I have not been able to find any information on how to fix this problem.

I have a self-hosted website and recently my SSL certificate expired. Tried creating a new one with the command sudo certbot certonly -d 'example.com,*.example.com' --manual --preferred-challenges dns. The command runs without problems producing the following errors, producing the following output:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Requesting a certificate for example.com and *.example.com

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/example.com/fullchain.pem
Key is saved at:         /etc/letsencrypt/live/example.com/privkey.pem
This certificate expires on 2023-05-09.
These files will be updated when the certificate renews.

NEXT STEPS:
- This certificate will not be renewed automatically. Autorenewal of --manual certificates requires the use of an authentication hook script (--manual-auth-hook) but one was not provided. To renew this certificate, repeat this same certbot command before the certificate's expiry date.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
If you like Certbot, please consider supporting our work by:
 * Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate 
 * Donating to EFF:                    https://eff.org/donate-le 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

But still, it doesn't work, when I check it with eg. https://www.sslshopper.com/ , it still shows the expired certificate. I waited more than a day and it's still nothing. Sidenote: I don't have any TXT records set up, certbot didn't ask me to set one up, like last time

i tested some things in docker and f*d up, also removed all containers and volumes including the certbot ones. so why is certbot still able to give me my certificates back? is it because they are stored somewhere in a web storage? is it because dockers storage driver keeps files even after deleting volumes/containers? is it because letsencrypt only needs a succesful DNS challenge and nothing more? i'm just curious how it works.. --- Addressing comments: > What do you mean by "give ... certificates back"? Are you sure it's not just generating a new certificate? with "give certs back" my thinking was, that i actually would need more than just my mail and dns possession. does this imply i don't need to back up the letsencrypt certificates and instead create new ones? what is the minimum requirement to "overwrite" then? thanks for help

I am setting up a new server and installing certbot on ubuntu 20. I am confused with sudo certbot certonly --webroot command of certbot. While running the command, it asks me input the webroot for domain.com. What should I put here? Note that it's a fresh ubuntu server and nothing else is installed except docker and certbot.