None taken.
So far, I can’t find anything wrong with the cert process.
One last test on that:
certbot certonly --cert-name communitygroat.co.uk --dry-run
And I can’t find anything terribly wrong with what you asked certbot to do.
It just seems to be confused…
I think you got it!
~]# certbot certonly --cert-name communitygroat.co.uk --dry-run
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Could not find ssl_module; not disabling session tickets.
How would you like to authenticate with the ACME CA?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: Apache Web Server plugin (apache)
2: Spin up a temporary webserver (standalone)
3: Place files in webroot directory (webroot)
Use:
#1 apache
Looks good. But this line:
Could not find ssl_module; not disabling session tickets.
Should I try again to enable mod_ssl, fingers crossed it works this time?
Please undo:
So you understand where I’m going.
There are two parts to --apache
#1 Authenticator
#2 Installer
So far, it seems the Authenticator is working flawlessly.
You got a cert
And you can renew that cert.
We haven’t even begun to test the Installer yet.
Ahh. OK. I configure a server once a flood so always out of date knowledge when I do. Very grateful for your guidance.
I don’t rightly know if we can force the installer to do all nine files.
But we can try…
Let’s see if it will do a single file at a time.
certbot renew --apache -d communitygroat.co.uk -d www.communitygroat.co.uk --dry-run
If that works - we win!
If that fails, try another one:
certbot renew --apache -d osspix.co.uk -d www.osspix.co.uk --dry-run
If that works… then there is a problem with the first config [doubtful].
If that also fails [expected], then we may need to “install” them ourselves.
The good news there is that you only have to do it once (per domain).
~]# certbot --apache -d communitygroat.co.uk -d www.communitygroat.co.uk --dry-run
--dry-run currently only works with the 'certonly' or 'renew' subcommands ('run')
OK OK. [certbot is so picky!]
certbot renew --apache -d communitygroat.co.uk -d www.communitygroat.co.uk --dry-run
[modified prev post]
~]# certbot --apache -d communitygroat.co.uk -d www.communitygroat.co.uk --dry-run
--dry-run currently only works with the 'certonly' or 'renew' subcommands ('run')
[root@dom01 ~]# certbot renew --apache -d communitygroat.co.uk -d www.communitygroat.co.uk --dry-run
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Currently, the renew verb is capable of either renewing all installed certificates that are due to be renewed or renewing a single certificate specified by its name. If you would like to renew specific certificates by their domains, use the certonly command instead. The renew verb may provide other options for selecting certificates to renew in the future.
OK I don’t think we can renew a cert for nine domains while only installing on one domain (at a time)…
Enter PLAN B:
We do it manually.
The installer is not able to do the work and I can’t say why.
But we have a viable “workaround”.
Can you make the TLS enabled vhost configs from the HTTP vhost configs?
[there should be plenty of examples on the web]
OR
Enter PLAN C:
We forget about that ONE SINGLE cert and get each domain its’ own cert.
How about that path?
[I’m leaning towards C - B is tedious and will require remembering to do manual stuff each time you add/remove a domain]
This is from the Wiki, including a file to add to /conf/extra/httpd.conf:
/etc/httpd/conf/extra/001-certbot.conf
<IfModule mod_ssl.c>
<VirtualHost *:443>
Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateFile /etc/letsencrypt/live/'domain'/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/'domain'/privkey.pem
</VirtualHost>
</IfModule>
Would adapting the VirtualHost contents be what we’re looking for?
Maybe, but I'm really not liking the idea of having to do anything manually - that doesn't scale nor pass the tests of time nor change in adminstratorship [if that's a word - I think you know what I meant].
I say chose the automated path - not the manual path.
If we can succeed at fully automating this…
Who cares if it is ten steps or one step or ten certs or one cert - it does it all on its’ own.
Indeed. I’m in complete agreement.
How about this one:
<VirtualHost *:443>
[some non-ssl stuff(directory, docroot)]
ServerName account.example.com
SSLEngine on
SSLCertificateFile /Users/myusername/certs/server.crt
SSLCertificateKeyFile /Users/myusername/certs/server.key
</VirtualHost>
OK
We don’t have to delete the “group” cert - we can do that after all nine are working individually.
Let’s start with the problem child:
certbot --apache -d communitygroat.co.uk -d www.communitygroat.co.uk
If is says anything about “you already have a cert that covers those names” - chose get a new cert.
[or if confusing options - post them here]
It appears to be still insisting upon that mod_ssl:
~]# certbot --apache -d communitygroat.co.uk -d www.communitygroat.co.uk
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Could not find ssl_module; not disabling session tickets.
Plugins selected: Authenticator apache, Installer apache
Obtaining a new certificate
Created an SSL vhost at /etc/httpd/conf/vhosts/communitygroat.co.uk-le-ssl.conf
Cannot find an SSLCertificateFile directive in /files/etc/httpd/conf/vhosts/communitygroat.co.uk-le-ssl.conf/IfModule/VirtualHost. VirtualHost was not modified
Unable to find an SSLCertificateFile directive
IMPORTANT NOTES:
- Unable to install the certificate
- Congratulations! Your certificate and chain have been saved at:
/etc/letsencrypt/live/communitygroat.co.uk-0001/fullchain.pem
Your key file has been saved at:
/etc/letsencrypt/live/communitygroat.co.uk-0001/privkey.pem
Your cert will expire on 2020-08-15. To obtain a new or tweaked
version of this certificate in the future, simply run certbot again
with the "certonly" option. To non-interactively renew *all* of
your certificates, run "certbot renew"
Did you undo the lines removed?