Renewal for subdomain hosted on different VS

I set up a subdomain a few months back to run Pleroma, a social media server. I managed to acquire a certificate using Let’s Encrypt. I don’t recall a problem at the time. I tried once to renew the certificate before it expired and came upon a problem, possibly relating to the certificate for the main domain at I must have set up redirects to https once I set up the certificate for the Pleroma virtual server. I am trying to understand the following error and currently suppose that it is due to the fact that certbot cannot access the website through http because of redirects. If this is correct, I presume I will have to reconfigure the sites-enabled file to permit http access before renewing.

If anybody can let me know if this is or is not in the right ball park, I will be grateful. Any additional pointers will be appreciated.

Many thanks :slight_smile:

My domain is:

[ has a valid certificate on a separate VS.]

I ran this command: certbot renew

It produced this output:

Processing /etc/letsencrypt/renewal/
Cert is due for renewal, auto-renewing...
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for
Waiting for verification...
Cleaning up challenges
Attempting to renew cert from /etc/letsencrypt/renewal/ produced an unexpected error: Failed authorization procedure. (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching Connection refused. Skipping.

All renewal attempts failed. The following certs could not be renewed:
  /etc/letsencrypt/live/ (failure)
1 renew failure(s), 0 parse failure(s)

 - The following errors were reported by the server:

   Type:   connection
   Detail: Fetching
   Connection refused

   To fix these errors, please make sure that your domain name was
   entered correctly and the DNS A record(s) for that domain
   contain(s) the right IP address. Additionally, please check that
   your computer has a publicly routable IP address and that no
   firewalls are preventing the server from communicating with the
   client. If you're using the webroot plugin, you should also verify
   that you are serving files from the webroot path you provided.

My web server is (include version): nginx 1.10.3

The operating system my web server runs on is (include version): Debian 9.5 (Stretch)

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


It does seems that your server implement too many redirection when aquiring validation… (However I’m not sure why an connection refused is presented)

Can you please share your Nginx configuration with us (for this specific virtual host)?

Thank you

Thanks for your reply. Yes, that will be new. I commented out a few lines to try (unsuccessfully) to stop redirecting to https. The following is the uncommented version as it was. Undoubtedly an unholy mess:

proxy_cache_path /tmp/pleroma-media-cache levels=1:2 keys_zone=pleroma_media_cache:10m max_size=10g
                 inactive=720m use_temp_path=off;

server {
    listen         80;
    return         301 https://$server_name$request_uri;

server {
    listen 443 ssl http2;
    ssl on;
    ssl_session_timeout 5m;

    ssl_certificate           /etc/letsencrypt/live/;
    ssl_certificate_key       /etc/letsencrypt/live/;

    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers "HIGH:!aNULL:!MD5 or HIGH:!aNULL:!MD5:!3DES";
    ssl_prefer_server_ciphers on;

    server_name example.tld;

    gzip_vary on;
    gzip_proxied any;
    gzip_comp_level 6;
    gzip_buffers 16 8k;
    gzip_http_version 1.1;
    gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript application/activity+json application/atom+xml;

    # the nginx default is 1m, not enough for large media uploads
    client_max_body_size 16m;

    location / {
        # if you do not want remote frontends to be able to access your Pleroma backend
        # server, remove these lines.
        add_header 'Access-Control-Allow-Origin' '*' always;
        add_header 'Access-Control-Allow-Methods' 'POST, GET, OPTIONS' always;
        add_header 'Access-Control-Allow-Headers' 'Authorization, Content-Type' always;
        if ($request_method = OPTIONS) {
            return 204;
        # stop removing lines here.

        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $http_host;

        proxy_pass http://localhost:4000;

        client_max_body_size 16m;

    location /proxy {
        proxy_cache pleroma_media_cache;
        proxy_cache_lock on;
        proxy_pass http://localhost:4000;

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