cat cidisraelDotOrg-le-ssl.conf
<IfModule mod_ssl.c>
<VirtualHost *:443>
ServerName cidisrael.org
ServerAlias www.cidisrael.org
ServerAdmin liberty@lc.org
DocumentRoot /var/www/html/webroot
#Available loglevels: trace8, ..., trace1, debug, info, notice, warn, error, crit, alert, emerg
LogLevel info
ErrorLog ${APACHE_LOG_DIR}/lc-error.log
CustomLog ${APACHE_LOG_DIR}/lc-access.log combined
#DirectoryIndex index.php
#<Directory /var/www/html/webroot/>
#AllowOverride None
#Options None
#Order allow,deny
#Allow from all
#</Directory>
Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateFile /etc/letsencrypt/live/cidisrael.org/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/cidisrael.org/privkey.pem
</VirtualHost>
</IfModule>cat cidisraelDotOrg-le-ssl.conf
<IfModule mod_ssl.c>
<VirtualHost *:443>
ServerName cidisrael.org
ServerAlias www.cidisrael.org
ServerAdmin liberty@lc.org
DocumentRoot /var/www/html/webroot
#Available loglevels: trace8, ..., trace1, debug, info, notice, warn, error, crit, alert, emerg
LogLevel info
ErrorLog ${APACHE_LOG_DIR}/lc-error.log
CustomLog ${APACHE_LOG_DIR}/lc-access.log combined
#DirectoryIndex index.php
#<Directory /var/www/html/webroot/>
#AllowOverride None
#Options None
#Order allow,deny
#Allow from all
#</Directory>
Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateFile /etc/letsencrypt/live/cidisrael.org/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/cidisrael.org/privkey.pem
</VirtualHost>
</IfModule>
1 Like
Both websites (dashboard.covenantjourney.org and cidisrael.org) have the same DocumentRoot (and thus the same content)?
it's complicated ... this client uses special software that allows all sites to go to the same directory and it gets sorted out from there
1 Like
Let's try something...
What's the output of:
sudo certbot certonly --webroot -w /var/www/html/webroot -d "cidisrael.org,www.cidisrael.org" --dry-run
this makes no sense to me ...
that domain already has a valid cert, yet your command worked:
certbot certonly --webroot -w /var/www/html/webroot -d "cidisrael.org,www.cidisrael.org" --dry-run
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Cert not due for renewal, but simulating renewal for dry run
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for cidisrael.org
http-01 challenge for www.cidisrael.org
Using the webroot path /var/www/html/webroot for all unmatched domains.
Waiting for verification...
Cleaning up challenges
IMPORTANT NOTES:
- The dry run was successful.
1 Like
never mind ... i see it turned into a renewal
1 Like
Astounding. Yet for the same webroot it fails for dashboard.covenantjourney.org. That tells me that something is intercepting the requests for dashboard.covenantjourney.org and looking elsewhere. The fact that the apache authenticator (--apache) also fails for dashboard.covenantjourney.org indicates this remapping is either preempting the apache vHost or overriding it.
I'm not sure what you mean.
i thought your certbot command was getting a new cert but it was just renewing an existing one
1 Like
It's a dry run so it has no effect (or relevance) on your existing certificates. It doesn't renew anything. 
The successful dry run for cidisrael.org helps us a lot with dashboard.covenantjourney.org because it indicates that there isn't any odd filtering happening (e.g. firewall) based on port number.
also ... you can actually go to https://dashboard.covenantjourney.org and if you accept the risk ... it goes to the right place
1 Like
something is forcing http to https though
1 Like
Yep. On both accounts. Yet somehow Let's Encrypt's validation request for dashboard.covenantjourney.org is not being redirected as indicated by certbot's output beginning with http.
1 Like
Let's try a generic sanity check...
Run this:
sudo apachectl -k graceful
Then post the output of this:
sudo apachectl -S
1 Like
what does that do ? this is a busy server
1 Like
It loads a new instance of apache with its own worker threads with the current apache configuration then lets the worker threads of the old apache instance die off naturally. Once all the old worker threads have closed, the old apache instance is closed.
1 Like
Basically, it ensures that the current apache configuration is actually being used by the worker threads responding to requests. Since changes to the apache configuration aren't pushed to the worker threads that already exist, we need to know that the new responsers are actually using the current configuration and not an old configuration stored in volatile memory.
1 Like
done
looks like it output the same long list as before (this server hosts over 250 domains):
VirtualHost configuration:
*:443 is a NameVirtualHost
default server cidisrael.org (/etc/apache2/sites-enabled/cidisraelDotOrg-le-ssl.conf:2)
port 443 namevhost cidisrael.org (/etc/apache2/sites-enabled/cidisraelDotOrg-le-ssl.conf:2)
alias www.cidisrael.org
...
port 443 namevhost covenantjourney.org (/etc/apache2/sites-enabled/covenantjourneyDotOrg-le-ssl.conf:2)
alias www.covenantjourney.org
...
*:80 is a NameVirtualHost
default server ### (/etc/apache2/sites-enabled/000-default.conf:1)
port 80 namevhost ### (/etc/apache2/sites-enabled/000-default.conf:1)
port 80 namevhost cidisrael.org (/etc/apache2/sites-enabled/cidisraelDotOrg.conf:1)
alias www.cidisrael.org
...
port 80 namevhost covenantjourney.org (/etc/apache2/sites-enabled/covenantjourneyDotOrg.conf:1)
alias www.covenantjourney.org
...
port 80 namevhost dashboard.covenantjourney.org (/etc/apache2/sites-enabled/dashDotCJdotOrg.conf:1)
...
ServerRoot: "/etc/apache2"
Main DocumentRoot: "/var/www/html"
Main ErrorLog: "/var/log/apache2/error.log"
Mutex ssl-stapling: using_defaults
Mutex proxy: using_defaults
Mutex ssl-cache: using_defaults
Mutex default: dir="/var/run/apache2/" mechanism=default
Mutex fcgid-pipe: using_defaults
Mutex watchdog-callback: using_defaults
Mutex rewrite-map: using_defaults
Mutex ssl-stapling-refresh: using_defaults
Mutex fcgid-proctbl: using_defaults
PidFile: "/var/run/apache2/apache2.pid"
Define: DUMP_VHOSTS
Define: DUMP_RUN_CFG
User: name="www-data" id=33
Group: name="www-data" id=33
1 Like
We often find here that people have made modifications to their apache configuration files then not reloaded the configuration, which makes any changes to the files unseen by the running apache.
1 Like