Today was the day for doing a manual renewal of my certificate, using certbot-auto. This did not go well for a while. First, when I tried using the nginx option, certbot expected nginx to be controlling port 443 ... but I was still running Rocket on that port. Finally, I stopped Rocket, did a --standalone update, and got my cert. Restarted Rocket, and got connection refused. Hmmm.
With further testing, I tried curl -g etc.etc from a sh session on the server; using the DNS name got refused curl -vv https://my.server.example.com * Failed to connect to my.server.example.com port 443: Connection refused * Closing connection 0 curl: (7) Failed to connect to my.server.example.com port 443: Connection refused Trying to connect to 127.0.0.1 failed for name match: curl -vv https://127.0.0.1 * Connected to 127.0.0.1 (127.0.0.1) port 443 (#0) * Initializing NSS with certpath: sql:/etc/pki/nssdb * CAfile: /etc/pki/tls/certs/ca-bundle.crt CApath: none * Server certificate: * subject: CN=my.server.example.com * start date: Nov 13 20:35:28 2017 GMT * expire date: Feb 11 20:35:28 2018 GMT * common name: my.server.example.com * issuer: CN=Let's Encrypt Authority X3,O=Let's Encrypt,C=US * NSS error -12276 (SSL_ERROR_BAD_CERT_DOMAIN) * Unable to communicate securely with peer: requested domain name does not match: There was nothing helpful in either httpserver.log or logs/web2py.log, even if I bumped the Rocket logging level up to DEBUG (The local access showed up as INFO, but not that it failed. The named access didn't show up at all.) Meanwhile, I have nginx listening to a different port but using the same certificate. Stopping and starting nginx, I get an error Starting nginx: nginx: [emerg] SSL_CTX_use_PrivateKey_file( "/etc/letsencrypt/live/dump.enmotus.com/privkey.key") failed (SSL: error: 0B080074:x509 certificate routines:X509_check_private_key:key values mismatch) That's pretty straight forward, and I did what the web search told me to do ... verify that the cert's public key and the public info in the private key file matched. They did. Verify that the server's cert was the first entry in the fullchain.pem file. It was. Finally, one of my coworkers saw that certbot had used relative links to point the entries in the letsencrypt/live/my.server.example.com directory to the correct entries in the letsencrypt/archive/my.server.example.com directory. I changed those to absolute links, and everything started to work again. Punchlines: 1. Rocket did not give any useful information about the problem, or even admit that there was a problem. 2. I didn't have the link problem on previous manual renewals, but I'm not sure whether the old links were relative or absolute. Has anyone else run across this? /dps -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list (Report Issues) --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
