Got an exception when expanding an existing certificate


#1

Letsencrypt is exiting abnormally when expanding an existing certificate by adding a new domain name with command

./letsencrypt-auto certonly --standalone -d os-vps276.projet-okinawa.org -d confluence.projet-okinawa.ch -d jira.projet-okinawa.ch -d openam.projet-okinawa.ch -d repo.projet-okinawa.ch -d www.projet-okinawa.ch -d www.blonay-lecentre.ch
Checking for new version...
Requesting root privileges to run letsencrypt...
   sudo /home/ubuntu/.local/share/letsencrypt/bin/letsencrypt certonly --standalone --test-cert -d os-vps276.projet-okinawa.org -d confluence.projet-okinawa.ch -d jira.projet-okinawa.ch -d openam.projet-okinawa.ch -d repo.projet-okinawa.ch -d www.projet-okinawa.ch -d www.blonay-lecentre.ch
2016-04-29 13:43:28,473:DEBUG:letsencrypt.main:Exiting abnormally:
Traceback (most recent call last):
File "/home/ubuntu/.local/share/letsencrypt/bin/letsencrypt", line 11, in 
sys.exit(main())
File "/home/ubuntu/.local/share/letsencrypt/local/lib/python2.7/site-packages/letsencrypt/main.py", line 692, in main
return config.func(config, plugins)
File "/home/ubuntu/.local/share/letsencrypt/local/lib/python2.7/site-packages/letsencrypt/main.py", line 509, in obtain_cert
_, action = _auth_from_domains(le_client, config, domains, lineage)
File "/home/ubuntu/.local/share/letsencrypt/local/lib/python2.7/site-packages/letsencrypt/main.py", line 90, in _auth_from_domains
renewal.renew_cert(config, domains, le_client, lineage)
File "/home/ubuntu/.local/share/letsencrypt/local/lib/python2.7/site-packages/letsencrypt/renewal.py", line 241, in renew_cert
prior_version = lineage.latest_common_version()
File "/home/ubuntu/.local/share/letsencrypt/local/lib/python2.7/site-packages/letsencrypt/storage.py", line 513, in latest_common_version
return max(n for n in versions[0] if all(n in v for v in versions[1:]))
ValueError: max() arg is an empty sequence

I opened issue 2903 for this case with the complete log file.
The first certificate was created by using --apache plugin.
Next certificates was created by using certonly --standalone to expand to other domain names.
Letsencrypt client encountered problem to identify correctly the configuration file name (the name of the directory where the certificate and keys are stored). It used two os-vps276.projet-okinawa.org (host fqdn) and confluence.projet-okinawa.ch. I was not able to change this (command or interactive). This is the reason I updated the symbolic link in /etc/live/os-vps276.projet-okinawa.org to points the one into confluence.projet-okinawa.ch. This was working fine until I requested the certificate to be expanded.


#2

Hi @micwic,

Changing the symlink has confused the client because it uses the symlink structure to determine which files are associated with the individual certificate lineage. Your change has made the client think that that certificate lineage is incomplete in some sense and it can’t figure out what symlinks to update in response to getting the new certificate.

It’s possible that the client ought to be more flexible in this respect (and it certainly should at least give a useful error message in this situation instead of crashing!), but for its current functionality, the change you made was not just cosmetic but unfortunately removed information that the client was relying on. In order to make the client able to renew that lineage without crashing, you’ll need to make the files’ naming structure consistent again from the client’s point of view, which could involve undoing your previous changes or else changing all of the directory names and the references in the renewal configuration file.


#3

I understand from your response the client is browsing the files and their content to determine the path to store the new certificate and the keys. Therefore, deleting the directory which doesn’t contain the last sequence of cert and keys, updating the name of the other one with the last updated cert and keys in archive, live and renewal (incl. symlink) should solve the problem. This is no other config or journal files relevant ?


#4

There’s also a config file in the renewal directory that will cause problems with the renew command if not updated.


#5

I solved everything by letting only one directory (move the wrong ones to a backup directory) in place (the one with all last certs and keys) and renaming it to the name the first one was created (the correct name). It was necessary to recreate the link in /etc/live (ln -sf target link_name). It was necessary also to update (directory name) the configuration file in /etc/renewal.


#6

@micwic, I’m glad things are working well for you now, and I’ll file an issue noting that we need to make the error messages in this kind of situation much clearer and more helpful.


#7

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