One important feature is an alpha version of the nginx plugin, which helps you configure nginx servers automatically in the same ways as Certbot's apache plugin does with Apache servers. The nginx plugin is still experimental, but we've tested it with a variety of configurations and it seems to be working.
We'd love to get feedback from Certbot users (or prospective users) who have nginx setups and are willing to experiment. When installing Certbot 0.9.0 (for example, via the certbot-auto method, or using pip and also requesting certbot-nginx), you can now specify certbot --nginx on the command line to indicate that you'd like to use the nginx integration. (Because nginx support is still in alpha test, you'll have to specify this explicitly; Certbot won't yet automatically suggest configuring your nginx server for you.)
This plugin fully automates the process of obtaining and installing certificates with Nginx. Additionally, it is able to automatically configure security enhancements such as an HTTP to HTTPS redirect and OCSP stapling. To use this plugin, you must have the certbot-nginx package installed (which is installed automatically when using certbot-auto) and provide --nginx on the command line. This plugin is still in its early stages so we recommend you use it with some caution and make sure you have a backup of your Nginx configuration.
I would also note that if you have an existing certificate installed in your nginx server but obtained via a different method (such as certonly with --webroot), you may be able to switch that certificate lineage over to use the nginx plugin with --nginx --force-renew -d one.example.com -d two.example.com -d three.example.com, but this isn't yet proven to work and you could conceivably end up with a duplicative certificate in some circumstances.
If you're up for trying the new plugin, please let us know about your experiences!
@schoen I’m testing this as we speak. First problem I got was
Failed authorization procedure. staging.myserve.co (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Failed to connect to 198.72.123.32:443 for TLS-SNI-01 challenge
I’ve found a few forum threads about the issue and will update as I go
@schoen If you have an existing SSL setup in place (not via Let’s Encrypt) is that going to cause issues? I’m wondering if that’s the problem here.
@pnomolos, there were some known issues with setups with existing certs, but it depends on what kind of redirection rules you have and what ports you’re listening on.
The error that you got basically suggests that the nginx plugin failed to reconfigure your nginx to satisfy the challenge, but we don’t know why. We would need to see more logs and maybe copies of your configuration file to diagnose the reason that it couldn’t reconfigure nginx. (The error from the server is just showing that, when the CA tried to verify the challenge, it hadn’t been set up properly.)
@schoen Disabling the existing SSL parameters did the trick (I may have even not needed to reload the configuration in between, just comment them out).
I added another server_name directive, and things appeared to work, but it added an extra
if ($scheme != "https") {
return 301 https://$host$request_uri;
} # managed by Certbot
block even though one existed. My site’s also stuck in a redirect loop now, I’m trying to sort out what changed that’s causing it
@schoen I think I may know what cause a bunch of the confusion. In order to force SSL I do the following:
server {
listen 80;
server_name domain.name;
return 301 https://$http_host$request_uri;
}
server {
listen 443;
server_name domain.name;
# ...
}
I’d have to do some more testing but I think that sort of set up caused both the issues. The first server block got merged with the cerbot configuration, but the return 301 https://$http_host$request_uri; remained intact, and the second block caused issues with the tls-sni-01 authorization.
Note: The reason I did things this way was due to a comment on performance - that it was faster to do this than use an if block.
@pnomolos, as you understand what’s wrong, it would be very helpful if you could open an issue on GitHub.
You can tag it with “bug” and “nginx” and, if you like, mention GitHub users ohemorange and bmw (who have been developing on the nginx parser and may be well-positioned to address the issue).
The first certificate(s) is/are fetched without SSL. Any changes or renewal-processes probably are tried with SSL then if everything went fine and the important question is if this change from http to https is working in general concerning the ACME-authentication.
The other things are partially more nginx-related and not much related to letsencrypt / certbot but surely it’s good having everything documented that it’s easier to understand.
