Reading back through your posts, the issue is the path that you're looking for the certificates in! I'm really sorry that I didn't spot that sooner. As per the docs, please check /var/lib/dehydrated/certs/ for the specific per domain certificates. I'll replay what I did to confirm it's working as expected:
Double check DNS is configured right (from my desktop):
That looks good! So ready to run the dehydrated-wrapper on my lamp server. First, my confconsole.domains.txt:
root@lamp ~# cat /etc/dehydrated/confconsole.domains.txt
# please use this file with confconsole or
# alternatively use dehydrated with it's appropriate
# configuration directly
jeremydavis.org lamp.jeremydavis.org
lamp-tester.tklapp.com
Now to run dehydrated. You shouldn't need the --force switch, but I do as I've already had this working and want to demonstrate the full process:
Looks like everything is in there. So all should be well. Although you'll still need to configure the individual webserver sites to use the relevant certificates. We haven't automated that because it will depend on the webserver being used and how you are configuring the sites. But it should be relatively straight forward if you understand how that works (it's is after all "advanced" functionality of confconsole).
Rereading the previous conversation again, I think what introduced your confusion is the log message "Writing cert.pem & cert.key for xyz.com to /etc/ssl/private".
FWIW, the docs do mention that the last cert to be written will be written there (and it is). Whats actually happening is that each cert is being written there, so each one overwrites the previous. In retrospect, I perhaps should have considered how I might make the log messages a bit clearer when multiple domains are used.
TBH, it was a last minute addition to support more complex use cases, and it wasn't implemented as well as it could have been. Also as I've noted, the docs aren't as clear as they should be. I'll spend a little more time on this and try to tidy it up a bit.
If you have any specific feedback on might be best, please let me know.
Hey Andi, deep apologies that it's taken me so long... :(
But you know what?! It works as expected for me!?
Reading back through your posts, the issue is the path that you're looking for the certificates in! I'm really sorry that I didn't spot that sooner. As per the docs, please check /var/lib/dehydrated/certs/ for the specific per domain certificates. I'll replay what I did to confirm it's working as expected:
Double check DNS is configured right (from my desktop):
That looks good! So ready to run the dehydrated-wrapper on my lamp server. First, my confconsole.domains.txt:
Now to run dehydrated. You shouldn't need the --force switch, but I do as I've already had this working and want to demonstrate the full process:
Now check in /var/lib/dehydrated/certs for the certificates: Looks like everything is in there. So all should be well. Although you'll still need to configure the individual webserver sites to use the relevant certificates. We haven't automated that because it will depend on the webserver being used and how you are configuring the sites. But it should be relatively straight forward if you understand how that works (it's is after all "advanced" functionality of confconsole).Rereading the previous conversation again, I think what introduced your confusion is the log message "Writing cert.pem & cert.key for xyz.com to /etc/ssl/private".
FWIW, the docs do mention that the last cert to be written will be written there (and it is). Whats actually happening is that each cert is being written there, so each one overwrites the previous. In retrospect, I perhaps should have considered how I might make the log messages a bit clearer when multiple domains are used.
TBH, it was a last minute addition to support more complex use cases, and it wasn't implemented as well as it could have been. Also as I've noted, the docs aren't as clear as they should be. I'll spend a little more time on this and try to tidy it up a bit.
If you have any specific feedback on might be best, please let me know.