Rollback on certificate created with --test-cert

rbrisita · August 17, 2017, 4:17pm

Please fill out the fields below so we can help you better.

My domain is:
https://aavm.eastus.cloudapp.azure.com

I ran this command:
sudo certbot --nginx rollback

It produced this output:
Saving debug log to /var/log/letsencrypt/letsencrypt.log

CONTENTS:

2017-08-17 16:00:27,540:DEBUG:certbot.main:certbot version: 0.17.0
2017-08-17 16:00:27,541:DEBUG:certbot.main:Arguments: ['--nginx']
2017-08-17 16:00:27,541:DEBUG:certbot.main:Discovered plugins: PluginsRegistry(PluginEntryPoint#manual,PluginEntryPoint#nginx,PluginEntryPoint#null,PluginEntryPoint#standalone,PluginEntryPoint#webroot)
2017-08-17 16:00:27,551:DEBUG:certbot.log:Root logging level set at 20
2017-08-17 16:00:27,551:INFO:certbot.log:Saving debug log to /var/log/letsencrypt/letsencrypt.log
2017-08-17 16:00:27,552:DEBUG:certbot.plugins.selection:No candidate plugin

My web server is (include version):
nginx version: nginx/1.10.3 (Ubuntu)

The operating system my web server runs on is (include version):
Ubuntu 16.04.3 LTS (Xenial Xerus)

My hosting provider, if applicable, is:
Azure Cloud

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 certificate was created with:

sudo certbot --nginx \
--domain aavm.eastus.cloudapp.azure.com \
--email ${EMAIL} \
--agree-tos \
--no-eff-email \
--non-interactive \
--test-cert

Without ‘–test-cert’, certbot complained about too many certificates for the azure.com domain. Which brings up another question of LetsEncrypt handling cloud hosts.

rg305 · August 17, 2017, 4:45pm

You could DNS CNAME "aavm.eastus.cloudapp.azure.com" from an FQDN under your control.
Given: The cert will then NOT contain "azure.com"

As for the "rollback" process: Is there a question I missed?

rbrisita · August 17, 2017, 4:49pm

Thanks, I’ll try the suggestion later.

In regard of the rollback process: after executing the command stated, the website still has HTTPS. In the debug output it states: 2017-08-17 16:00:27,552:DEBUG:certbot.plugins.selection:No candidate plugin

I was wondering if rollback needs --test-cert to work (tried and failed) as does the revoke command.

rg305 · August 17, 2017, 4:54pm

Yeah, I don’t think you can revoke test certs.
Not sure why rollback didn’t put things back the way they were previously (which is what I suspect you want).

rbrisita · August 17, 2017, 5:13pm

Okay, so no rollback on test certs. Would you suggest then doing:

sudo certbot revoke --test-cert --cert-path /etc/letsencrypt/live/aavm.eastus.cloudapp.azure.com/fullchain.pem

sudo certbot delete --cert-name aavm.eastus.cloudapp.azure.com

Then modifying /etc/nginx/sites-available/default and restarting Nginx to get the rollback effect?

schoen · August 17, 2017, 5:18pm

Hi @rbrisita,

@rg305 suggested that you can't revoke test certs, not that you can't rollback test certs. In Certbot, "rollback" means undoing changes that Certbot previously made to your web server configuration, not anything about the existence or validity of a certificate. Is that what you wanted to do?

The error that you're getting is possibly unrelated to the fact that it was a test certificate. What command did you use to obtain the certificate?

rbrisita · August 18, 2017, 12:42pm

Hey @schoen,

Thanks for explaining what rollback was suppose to do. I’ll paste my exact steps:

Create Certificate:

sudo certbot --nginx \
--domain aavm.eastus.cloudapp.azure.com \
--email valid.email@gmail.com \
--agree-tos \
--no-eff-email \
--non-interactive \
--test-cert

Tested HTTPS on website and all good.

Rollback:

sudo certbot --nginx rollback

Rollback Output:

Saving debug log to /var/log/letsencrypt/letsencrypt.log

/var/log/letsencrypt/letsencrypt.log:

2017-08-17 16:00:27,540:DEBUG:certbot.main:certbot version: 0.17.0
2017-08-17 16:00:27,541:DEBUG:certbot.main:Arguments: ['--nginx']
2017-08-17 16:00:27,541:DEBUG:certbot.main:Discovered plugins: PluginsRegistry(PluginEntryPoint#manual,PluginEntryPoint#nginx,PluginEntryPoint#null,PluginEntryPoint#standalone,PluginEntryPoint#webroot)
2017-08-17 16:00:27,551:DEBUG:certbot.log:Root logging level set at 20
2017-08-17 16:00:27,551:INFO:certbot.log:Saving debug log to /var/log/letsencrypt/letsencrypt.log
2017-08-17 16:00:27,552:DEBUG:certbot.plugins.selection:No candidate plugin

At this point /etc/nginx/sites-available/default has not been changed and the website still has HTTPS.

Please let me know if you need any more information.

schoen · August 18, 2017, 5:34pm

@erica, could this perhaps be an actual bug related to plugin selection? It seems like @rbrisita has the nginx plugin installed because the original certbot --nginx works and does not log the same error. (I feel like we haven’t been testing or emphasizing the rollback features as much since James stopped working on Certbot.)

erica · August 18, 2017, 7:44pm

Working on reproducing, to check this out. @rbrisita, how did you install Certbot?

erica · August 18, 2017, 7:58pm

Ok, I think there’s actually something else going on here. For one, if you used --test-cert, HTTPS on website should not have been “all good”. For another, without making manual changes beforehand, Certbot doesn’t make any changes to /etc/nginx/sites-available/default.

So what I’m interested in seeing is:

The output of certbot certificates
The contents of /etc/nginx/sites-available/default (ideally both before and after the change)
The contents of any other nginx config files that might be lying around
The output of certbot config_changes

After you’ve done these, you can try running sudo certbot rollback a few more times, because maybe multiple changes were made and it just didn’t roll back far enough.

rbrisita · August 20, 2017, 3:16pm

Hi @erica,

To be a little clearer: “all good” in the sense that it used SSL from the ‘Fake LE Intermediate X1’ issuer.

Install

sudo add-apt-repository -y ppa:certbot/certbot
sudo apt-get update
sudo apt-get -y install python-certbot-nginx certbot

certbot certificates output

Saving debug log to /var/log/letsencrypt/letsencrypt.log

-------------------------------------------------------------------------------
Found the following certs:
  Certificate Name: aavm.eastus.cloudapp.azure.com
    Domains: aavm.eastus.cloudapp.azure.com
    Expiry Date: 2017-11-18 13:52:00+00:00 (INVALID: TEST_CERT)
    Certificate Path: /etc/letsencrypt/live/aavm.eastus.cloudapp.azure.com/fullchain.pem
    Private Key Path: /etc/letsencrypt/live/aavm.eastus.cloudapp.azure.com/privkey.pem
-------------------------------------------------------------------------------

/etc/nginx/sites-available/default

server {
    listen 80 default_server;
    listen [::]:80 default_server;

    root /var/www/html;
    index index.php index.html index.htm index.nginx-debian.html;

    server_name aavm.eastus.cloudapp.azure.com;

    location / {
	try_files $uri $uri/ /index.php?$query_string;
    }

    location ~ [^/]\.php(/|$) {
	# Secure path parsing.
        include snippets/fastcgi-php.conf;

	# Mitigate https://httpoxy.org/ vulnerabilities.
	fastcgi_param HTTP_PROXY "";

        fastcgi_pass unix:/run/php/php7.1-fpm.sock;
    }

    location ~ /\.ht {
        deny all;
    }

    listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/aavm.eastus.cloudapp.azure.com/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/aavm.eastus.cloudapp.azure.com/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot

}

Prior would be without the ‘managed by Certbot’ comments, which I would think the command rollback would remove.

tree /etc/nginx/

/etc/nginx/
├── conf.d
├── fastcgi.conf
├── fastcgi_params
├── koi-utf
├── koi-win
├── mime.types
├── nginx.conf
├── proxy_params
├── scgi_params
├── sites-available
│   ├── backup_default_2017-08-17:01:22:22
│   └── default
├── sites-enabled
│   └── default -> /etc/nginx/sites-available/default
├── snippets
│   ├── fastcgi-php.conf
│   └── snakeoil.conf
├── uwsgi_params
└── win-utf

4 directories, 15 files

Let me know which file interests you and I’ll post the contents.

certbot config_changes

Saving debug log to /var/log/letsencrypt/letsencrypt.log

-------------------------------------------------------------------------------
Sun Aug 20 14:52:16 2017
-- Deployed ACME Certificate --
Changed vhost at /etc/nginx/sites-enabled/default with addresses of 443 ssl,
[::]:80 default_server, 80 default_server
        ssl_certificate
/etc/letsencrypt/live/aavm.eastus.cloudapp.azure.com/fullchain.pem
        ssl_certificate_key
/etc/letsencrypt/live/aavm.eastus.cloudapp.azure.com/privkey.pem

Affected files:
  /etc/nginx/nginx.conf
  /etc/nginx/mime.types
  /etc/nginx/sites-enabled/default


Thu Aug 17 02:19:16 2017
-- Deployed ACME Certificate --
Changed vhost at /etc/nginx/sites-enabled/default with addresses of 443 ssl,
[::]:80 default_server, 80 default_server
        ssl_certificate
/etc/letsencrypt/live/aavm.eastus.cloudapp.azure.com/fullchain.pem
        ssl_certificate_key
/etc/letsencrypt/live/aavm.eastus.cloudapp.azure.com/privkey.pem

Affected files:
  /etc/nginx/nginx.conf
  /etc/nginx/mime.types
  /etc/nginx/sites-enabled/default

-------------------------------------------------------------------------------

I have tried sudo certbot rollback multiple times but all it’ll output was the saving debug to the log file.

rbrisita · August 23, 2017, 3:18pm

@erica and @schoen please let me know if you need further assistance. I will be monitoring this post through email now.

erica · August 25, 2017, 6:10pm

Ah. I see what’s happening. This is happening because the Nginx plugin isn’t officially supported in 0.17.0. This will be fixed with 0.18.0, which unhides Nginx. 0.18.0 will be released in about a week and a half. To fix this beforehand, you can manually delete the # managed by Certbot lines in your configuration file, which is all that rollback does anyway.

There’s also a bug here, in that --nginx isn’t being recognized for the rollback subcommand, but that’s on us. Thanks for catching that!

erica · August 25, 2017, 6:36pm

Or, as @bmw helpfully pointed out, use --installer nginx, which does solve this problem right now.

system · September 24, 2017, 6:36pm

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