Cert is due for renewal, auto-renewing...
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
Renewing an existing certificate
Performing the following challenges:
tls-sni-01 challenge for books.pointerstop.ca
tls-sni-01 challenge for pointerstop.ddns.net
/usr/lib/python2.7/dist-packages/OpenSSL/rand.py:58: UserWarning: implicit cast from 'char *' to a different pointer type: will be forbidden in the future (check that the types are as you expect; use an explicit ffi.cast() if they are correct)
result_code = _lib.RAND_bytes(result_buffer, num_bytes)
Waiting for verification...
Cleaning up challenges
Attempting to renew cert from /etc/letsencrypt/renewal/books.pointerstop.ca.conf produced an unexpected error: Failed authorization procedure. pointerstop.ddns.net (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: DNS problem: NXDOMAIN looking up A for pointerstop.ddns.net. Skipping.
The following certs are not due for renewal yet:
/etc/letsencrypt/live/gis.pointerstop.ca/fullchain.pem (skipped)
All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/books.pointerstop.ca/fullchain.pem (failure)
1 renew failure(s), 0 parse failure(s)
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.
Yes. That's because you originally got a certificate covering bothbooks.pointerstop.ca and pointerstop.ddns.net. So when you try to renew it, it tries to renew with both of those domains to give you a renewal of the same certificate.
Presumably now you want a certificate just for books.pointerstop.ca. See the documentation on changing the domains on a certificate (other than --cert-name and -d, use the same options as you did when requested the certificate originally).
A convenient but possibly slightly risky alternative in Certbot is renewing with--allow-subset-of-names. This will continue with the renewal even if some of the names in the certificate can't be renewed. It's risky particularly because it ignores all failed domains, regardless of the reason that each one failed.
Fine (and I actually got it fixed with “certbot --apache” and just
specifying the domains I wanted), but why can’t the MESSAGE tell me that? I
shouldn’t have to either ask here or check the documentation, to find that
there’s not actually a problem with the certificate that it said there was
a problem with!
“Attempting to renew cert from
/etc/letsencrypt/renewal/books.pointerstop.ca.conf produced an unexpected
error: Failed authorization procedure. pointerstop.ddns.net” implies a
problem with “books.pointerstop.ca”. It was only when I got it to work with
the new domains and it gave me “XXXX.pointerstop.ca.conf” (where XXXX was
not either the alphabetically first, nor the first to appear in the
available domains to select) that it was apparent that the name of that
.conf file is not remotely the name of the problem domain.
And, in fact, I had three domains. The third one is never mentioned.
certbot is supposed to be making SSL certificates easy for the masses.
Surely it should renew the certificates it can, and then tell you that it
can’t renew the rest?
Well, duh… That came in while I was composing my reply, and clearly I should have read it first!
Why do you consider it (even slightly) risky? It’s exactly what I should have used, and I don’t see the downside. So, a domain I can no longer access can’t be renewed. Perhaps it’s not, as in my case, a domain I’ve actually dropped, but it’s still a domain that LetsEncrypt should not be renewing without active intervention. Whereas, the other domains, that you can reach, are clearly valid. Seems like this should be the default, not something people are reluctant to recommend.
On this forum, we see dozens of transitory, accidental renewal problems every day, where people have minor DNS errors or something, or have changed their web server configurations. It seems like most of those people didn’t mean to drop the associated domain names from their certificates and indeed want to be told whether the renewal would imply a change in the certificate content! (Many certificates cover quite large numbers of different domain names, up to 100; and many of the errors can be outside of the control of the person performing the renewal, as when a DNS provider has an outage or something.)
That's exactly what it does However, it couldn't renew that particular certificate because you had both domains on the same certificate. If you put each domain on its own certificate, certbot will indeed renew the ones it can, and retry the others later.
A simple way to put it might be that if you routinely use --allow-subset-of-names, you can easily lose names that you didn’t mean to lose, and you won’t notice until people’s browsers start returning errors on the site.
LOL. Different strokes, I guess. I really wouldn’t have thought that people renewing a hundred domains were using LetsEncrypt. I can see your reasoning for not making it the default, but still hardly risky!
Well, I had both domains on the same certificate because there’s nothing in the beginners guide to LetsEncrypt that suggests that’s what will happen. You run certbot, and it asks you what domains you want certificates for. There’s no suggestion that if you don’t want annoying interconnections you should run it five times if you have five domains.
This is good feedback! Digging a little deeper, I would say the root cause here is that Certbot was designed when rate limits were fairly tight (5 certificates per domain per week), and was designed to assume you wanted to combine names on a certificate wherever possible. Since then, the rate limit has increased to 20, so combining certificates is less valuable. At the same time, what we've learned through experiences like yours is that putting a single name on each certificate tends to be more robust to this type of failure. It may be worthwhile to rethink the Certbot defaults! One slight complication is that if two server_names are on the same vhost in a web server config, it may be impossible to put them on separate certificates without radically rewriting the config.
I'll also note that the Certbot design for storing certificate issuance preferences is part of what makes --allow-subset-of-names risky. Because the set of current certificates in the Certbot config directory is considered the canonical reference for which domains are desired, dropping any domain means it is permanently dropped. If we were to switch to a system where we store the desired names separately from the actually issued certificates, this feature would be much safer; even if you drop a domain on this renewal, you might bring it back on the next renewal. @bmw@pde@erica.
This has proved to be a very tricky design space. There is a case for having a list of “desired domains” that gets recorded when --allow-subset-of-names actually does something, but there’s a risk it would lead to a bunch of implementation complexity.
I’m not sure I’d want to encourage more complexity in Certbot; I think it’s safe to provide just a little more information. Just a note to say that if you select multiple domains they’ll all be on one certificate, and need to be renewed together, otherwise the user should run certbot for each domain, would help immensely.
Anyway, thanks for all your very pertinent feedback. This is why LetsEncrypt is #1
… although I’ll admit I’ve used it myself on occasion!
However, it couldn't renew that particular certificate because you had both domains on the same certificate. If you put each domain on its own certificate, certbot will indeed renew the ones it can, and retry the others later.