vhost listing for new domain kills all my domains
Background: I have about a dozen websites sharing a server, and have an SSL certificate covering all of them. (I'm using letsencrypt and certbot.) Domains are registered on GoDaddy. Life is good.
I recently needed to add another website/domain to the mix (womenofaction.club). I've done that before, no sweat. Except this time.
When I include the VirtualHost record on vhost.conf block bracketed by VirtualHost *:80 and /VirtualHost (with < and > in both cases, can't include here because it screws up the presentation) -- here's the rest of the lines:
ServerAdmin [my email address]
ServerName womenofaction.club
ServerAlias www.womenofaction.club
DocumentRoot /srv/www/womenofaction.club/public_html/
ErrorLog /srv/www/womenofaction.club/logs/error.log
CustomLog /srv/www/womenofaction.club/logs/access.log combined
RewriteEngine on
RewriteCond %{SERVER_NAME} =womenofaction.club [OR]
RewriteCond %{SERVER_NAME} =www.womenofaction.club
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
…modeling after all the other ones, only change being made being the domain name, none of my websites can be accessed. But using a browser to access womenofaction.club instead opens a website that is the first one listed on all the vhost.conf blocks.
When I comment out all this lines, bingo, my other sites can now be accessed.
Is the new website really there?
-- There is a legitimate index page at /srv/www/womenofaction.club/public.html .
-- nslookup womenofaction.club resolves to the correct IP address, 45.56.67.89.
-- And ping womenofaction.club works fine.
That seems to assure me that the DNS settings are good.
I've stared at that vhost.conf listing looking for some bonehead mistake.
I've rearranged the order so that the new block is sandwiched between existing blocks. Problem persists.
I understand that I must first have a website running before I can get an SSL certificate for it; seems reasonable of course. So, until I can get this website up without taking down my other sites (!!!!), I can't proceed with getting the certificate.
Desparately looking for a solution.
18 Replies
✓ Best Answer
Maybe the confusion has to do with me striving to get SSL, not TSL.
SSL is obsolete. It’s been cracked. Nothing supports it…and hasn’t for quite awhile. Both my web server and email server will _ summarily reject_ your connection if you present any flavor of SSL. To do anything else would make my system vulnerable to attack… If you're using Let's Encrypt, your web server will do the same (this is from the Let's Encrypt glue for apache web servers):
SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
This means all security protocols EXCEPT SSLv2 SSLv3 TLSv1 TLSv1.1 are accepted (effectively only TLSv1.2 or better). SSLv1 never made it out of the lab.
TLS (transport level security) is the successor to SSL. People often use the acronyms SSL & TLS interchangeably. That’s incorrect. What you are using is TLS…period.
I'm reading this:
https://www.ssl2buy.com/wiki/ssl-vs-tls
You didn't read far enough:
In nutshell, SSL is obsolete and TLS is new name of older SSL protocol as modern encryption standard using by everybody. Technically, TLS is more accurate, but everyone knows SSL.
That would explain port 80, right?
No. The purpose of the vhost is to give you a place to define the ServerName/ServerAlias, DocumentRoot, logging set up, and a place to define the redirect to the corresponding secure site. The use of port 80 is because you redirect to the same url using port 443. Each of your virtual hosts constructs a permanent redirect to some other url on your server (a secure site using https — de facto port 443). That’s what all the Rewrite* directives in each vhost do for you:
RewriteEngine on
RewriteCond %{SERVER_NAME} =womenofaction.club [OR]
RewriteCond %{SERVER_NAME} =www.womenofaction.club
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
If you used port 443 for your vhost definition, your redirect would be an endless loop and you’d get a too many redirects error.
The redirect is confirmed by a simple set of shell commands to follow redirects and show them to you:
stevewi:~ $ url=http://sme62.org #set the starting point
stevewi:~ $ while redirect_url=$(curl -I -s -S -f -w "%{redirect_url}\n" -o /dev/null "$url")
> do
> echo "$url"
> url=$redirect_url
> [[ -z "$url" ]] && break # terminate loop when $url is empty
> done
You get:
http://sme62.org # << redirected url
https://sme62.org/ # << final location
The one problem I am having, that stands in the way, is why the VirtualHost block for the womenofaction.club causes all my sites to be inaccessible, when it matches the format of all the existing websites. I see nothing unique to womenofaction.club compared to other sites.
None of that means anything… You're engaging in the "correlation = (non-)causation" fallacy here.
What I would do is fix your Let’s Encrypt cert using the bare-bones vhost I presented in my last post. Once the cert is updated, try the full monty vhost again.
That’s the simplest thing to do at this point. If that doesn’t work, you’re prob in for a lost weekend restructuring your web server configuration.
— sw
P.S. When I point my browser to http://womenofaction.club, I am redirected to https://saddlebrookeranch.org.
Desparately [sic] looking for a solution.
Try looking at the apache2 error log or doing sudo apachectl -t -D DUMP_INCLUDES to show all included configuration files and check the validity of your configuration.
-- sw
This is a common issue with lots of causes and solutions. See:
The first thing I'd do is to have certbot update the ssl certs on each domain individually and that might fix it.
My guess is the error is in womenofaction.club-le-ssl.com .
It would really help if we can see the entire vhost records(s). See the "cheat sheet" on using backticks to format here. http://demo.showdownjs.com/#!#code-formatting
stevewi -- Doing this: sudo apachectl -t -D DUMP_INCLUDES, got this…
"Passing arguments to httpd using apachectl is no longer supported.
You can only start/stop/restart httpd using this script.
If you want to pass extra arguments to httpd, edit the
/etc/sysconfig/httpd config file.
Syntax OK"
"Syntax OK" is helpful.
stevewi -- where is the apache2 error log. I thought I tracked is down, but found that the folder of interest was empty.
Passing arguments to httpd using apachectl is no longer supported. You can only start/stop/restart httpd using this script. If you want to pass extra arguments to httpd, edit the /etc/sysconfig/httpd config file.
Stupid Linux packaging tricks…another reason why Linux distros suck…
Try this: sudo apachectl -M. -M is a synonym for -t -D DUMP_INCLUDES.
where is the apache2 error log. I thought I tracked is down, but found that the folder of interest was empty.
Usually it's in /var/log someplace.
-- sw
P.S. They're directories…not folders…
acanton77 -- The new domain is not included in womenofaction.club-le-ssl.com because there is no certificate for it yet. The instructions I am following is to first get the website up, so there is something to certify, then get a certificate.
Also, I have one certificate that covers all of the domains (excluding the one for which I am having the trouble.
Here's the complete vhost.conf. Notice the block for womenofaction.club is commented out so my other websites come up. The very last block is commented out because I'm not yet sure if I want to create that website:
<VirtualHost *:80>
ServerAdmin ken.gorman@me.com
ServerName saddlebrookeranch.org
ServerAlias www.saddlebrookeranch.org
DocumentRoot /srv/www/saddlebrookeranch.org/public_html/
ErrorLog /srv/www/saddlebrookeranch.org/logs/error.log
CustomLog /srv/www/saddlebrookeranch.org/logs/access.log combined
RewriteEngine on
RewriteCond %{SERVER_NAME} =www.saddlebrookeranch.org [OR]
RewriteCond %{SERVER_NAME} =saddlebrookeranch.org
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>
<VirtualHost *:80>
ServerAdmin ken.gorman@me.com
ServerName enfeedia.com
ServerAlias www.enfeedia.com
DocumentRoot /srv/www/enfeedia.com/public_html/
ErrorLog /srv/www/enfeedia.com/logs/error.log
CustomLog /srv/www/enfeedia.com/logs/access.log combined
RewriteEngine on
RewriteCond %{SERVER_NAME} =www.enfeedia.com [OR]
RewriteCond %{SERVER_NAME} =enfeedia.com
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>
<VirtualHost *:80>
ServerAdmin ken.gorman@me.com
ServerName sme62.org
ServerAlias www.sme62.org
DocumentRoot /srv/www/sme62.org/public_html/
ErrorLog /srv/www/sme62.org/logs/error.log
CustomLog /srv/www/sme62.org/logs/access.log combined
RewriteEngine on
RewriteCond %{SERVER_NAME} =www.sme62.org [OR]
RewriteCond %{SERVER_NAME} =sme62.org
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>
<VirtualHost *:80>
ServerAdmin ken.gorman@me.com
ServerName llgorman.com
ServerAlias www.llgorman.com
DocumentRoot /srv/www/llgorman.com/public_html/
ErrorLog /srv/www/llgorman.com/logs/error.log
CustomLog /srv/www/llgorman.com/logs/access.log combined
RewriteEngine on
RewriteCond %{SERVER_NAME} =www.llgorman.com [OR]
RewriteCond %{SERVER_NAME} =llgorman.com
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>
<VirtualHost *:80>
ServerAdmin ken.gorman@me.com
ServerName storiesofpetsbypetsforpets.com
ServerAlias www.storiesofpetsbypetsforpets.com
DocumentRoot /srv/www/storiesofpetsbypetsforpets.com/public_html/
ErrorLog /srv/www/storiesofpetsbypetsforpets.com/logs/error.log
CustomLog /srv/www/storiesofpetsbypetsforpets.com/logs/access.log combined
RewriteEngine on
RewriteCond %{SERVER_NAME} =www.storiesofpetsbypetsforpets.com [OR]
RewriteCond %{SERVER_NAME} =storiesofpetsbypetsforpets.com
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>
<VirtualHost *:80>
ServerAdmin ken.gorman@me.com
ServerName keligo.com
ServerAlias www.keligo.com
DocumentRoot /srv/www/keligo.com/public_html/
ErrorLog /srv/www/keligo.com/logs/error.log
CustomLog /srv/www/keligo.com/logs/access.log combined
RewriteEngine on
RewriteCond %{SERVER_NAME} =keligo.com [OR]
RewriteCond %{SERVER_NAME} =www.keligo.com
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>
#<VirtualHost *:80>
# ServerAdmin ken.gorman@me.com
# ServerName womenofaction.club
# ServerAlias www.womenofaction.club
# DocumentRoot /srv/www/womenofaction.club/public_html/
# ErrorLog /srv/www/womenofaction.club/logs/error.log
# CustomLog /srv/www/womenofaction.club/logs/access.log combined
# RewriteEngine on
#RewriteCond %{SERVER_NAME} =womenofaction.club [OR]
#RewriteCond %{SERVER_NAME} =www.womenofaction.club
#RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
#</VirtualHost>
<VirtualHost *:80>
ServerAdmin ken.gorman@me.com
ServerName packetstacks.com
ServerAlias www.packetstacks.com
DocumentRoot /srv/www/packetstacks.com/public_html/
ErrorLog /srv/www/packetstacks.com/logs/error.log
CustomLog /srv/www/packetstacks.com/logs/access.log combined
RewriteEngine on
RewriteCond %{SERVER_NAME} =packetstacks.com [OR]
RewriteCond %{SERVER_NAME} =www.packetstacks.com
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>
#<VirtualHost *:80>
# ServerAdmin ken.gorman@me.com
# ServerName sbr.cloud
# ServerAlias www.sbr.cloud
# DocumentRoot /srv/www/sbr.cloud/public_html/
# ErrorLog /srv/www/sbr.cloud/logs/error.log
# CustomLog /srv/www/sbr.cloud/logs/access.log combined
#RewriteEngine on
#RewriteCond %{SERVER_NAME} =sbr.cloud [OR]
#RewriteCond %{SERVER_NAME} =www.sbr.cloud
#RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
#</VirtualHost>
stevewi -- Not exactly where you said, but I think this is what you are asking for:
[ken@alpha log]$ sudo cat httpd/error_log
[Sun Sep 25 03:16:02.005230 2022] [lbmethod_heartbeat:notice] [pid 840] AH02282: No slotmem from mod_heartmonitor
[Sun Sep 25 03:16:02.015882 2022] [ssl:warn] [pid 840] AH02292: Init: Name-based SSL virtual hosts only work for clients with TLS server name indication support (RFC 4366)
[Sun Sep 25 03:16:02.170240 2022] [mpm_prefork:notice] [pid 840] AH00163: Apache/2.4.6 (CentOS) OpenSSL/1.0.2k-fips PHP/7.3.33 configured -- resuming normal operations
[Sun Sep 25 03:16:02.170278 2022] [core:notice] [pid 840] AH00094: Command line: '/usr/sbin/httpd -D FOREGROUND'
About that [ssl:warn]. all my domains are under one certificate, so if works for one, should work for all …no? I can't figure out what's unique about womenofaction.club. It's done just like all the others, including DNS settings.
stevewi --
[ken@alpha /]$ sudo cd apachectl -M
[sudo] password for ken:
/bin/cd: line 2: cd: apachectl: No such file or directory
acanton77 --
I'm working through results of that google search recommended. Lots of stuff there, will take some study.
Here's something, don't know how to interpret it:
[ken@alpha etc]$ cat hosts
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
45.56.67.89 alpha.keligo.com alpha
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
I looked at that in response to a comment by someone having a problem that might be like mine:
Hello, you need to add 127.0.0.1 example.com in your /etc/hosts file.
Here's something, don't know how to interpret it:
[ken@alpha etc]$ cat hosts
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
IP-address-redacted alpha.keligo.com alpha
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
I looked at that in response to a comment by someone having a problem that might be like mine:
Hello, you need to add 127.0.0.1 example.com in your /etc/hosts file.
/etc/hosts/ is a short-circuit (if you will) to DNS. In the above snippet, the names localhost localhost.localdomain localhost4 localhost4.localdomain4 will all resolve to the IP address 127.0.0.1 (the IPv4 loopback address). The names localhost localhost.localdomain localhost6 localhost6.localdomain6 will all resolve to the IP address ::1 (the IPv6 loopback address). The names alpha.keligo.com alpha will all resolve to the IP address IP-address-redacted. All of this will happen without bothering DNS (or taking up space in your server's DNS cache). The caveat here is that /etc/hosts only applies to the system on which it lives. So, if you go to another system where you don't have the entry:
IP-address-redacted alpha.keligo.com alpha
referencing alpha.keligo.com will cause DNS queries to accomplish name resolution and referencing alpha will probably yield an error (unknown host or some such).
You continue…
About that [ssl:warn]. all my domains are under one certificate, so if works for one, should work for all …no? I can't figure out what's unique about womenofaction.club. It's done just like all the others, including DNS settings.
Nope… (Let's Encrypt) certs are domain specific (wildcard certs notwithstanding). That's why you have to give the domain name to certbot. You can enumerate all the domains for the cert when you acquire/renew it:
certbot cert-only ... -d foo.com,bar.com,baz.com
Is that what you mean by all my domains are under one certificate?
Just FYI, you defined another error log for your problem domain (from your OP):
ErrorLog /srv/www/womenofaction.club/logs/error.log
CustomLog /srv/www/womenofaction.club/logs/access.log combined
Also, none of your sites use TLS. You have
<VirtualHost *:80>...</VirtualHost>
for every single one of them. Port 443 is for https (e.g., <VirtualHost *:443>...</VirtualHost>). None of your vhosts use any of the letsencrypt glue (from one of mine):
...
Include /usr/local/etc/letsencrypt/options-ssl-apache.conf
SSLCertificateFile /usr/local/etc/letsencrypt/live/mydomain.com/cert.pem
SSLCertificateKeyFile /usr/local/etc/letsencrypt/live/mydomain.com/privkey.pem
SSLCACertificateFile /usr/local/etc/letsencrypt/live/mydomain.com/chain.pem
...
SSLOptions +StdEnvVars
...
DON'T just copy/paste all this stuff in your vhost configs. This is specific to me (I'm giving it as an example).
That any of this works at all just amazes me…you have been extremely lucky. My diagnosis would be that your luck has run out.
While you're fixing all of this, take each one of these out of vhosts.conf and put them in files in /etc/apache2/sites-available with a single vhost config per file. That way, you'll be able to enable/disable them with a2ensite/a2dissite.
-- sw
P.S.
[ken@alpha /]$ sudo cd apachectl -M
[sudo] password for ken:
/bin/cd: line 2: cd: apachectl: No such file or directory
Compare this against what I actually posted about this…see if your can find your mistake.
P.P.S. Just for yuxs:
stevewi:~ $ curl -vvI https://womenofaction.club
* Trying IP-address-redacted:443...
* Connected to womenofaction.club (45.56.67.89) port 443 (#0)
* ALPN: offers h2
* ALPN: offers http/1.1
* CAfile: /usr/local/share/certs/ca-root-nss.crt
* CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS alert, unknown CA (560):
* SSL certificate problem: self signed certificate
* Closing connection 0
curl: (60) SSL certificate problem: self signed certificate
More details here: https://curl.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
Also, according to this, it looks like some PHP entity (Wordpress?) is handling the cert & TLS setup:
stevewi:~ $ curl -vvI https://sme62.org
* Trying IP-address-redacted:443...
* Connected to sme62.org (IP-address-redacted) port 443 (#0)
* ALPN: offers h2
* ALPN: offers http/1.1
* CAfile: /usr/local/share/certs/ca-root-nss.crt
* CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN: server did not agree on a protocol. Uses default.
* Server certificate:
* subject: CN=enfeedia.com
* start date: Aug 27 13:03:12 2022 GMT
* expire date: Nov 25 13:03:11 2022 GMT
* subjectAltName: host "sme62.org" matched cert's "sme62.org"
* issuer: C=US; O=Let's Encrypt; CN=R3
* SSL certificate verify ok.
> HEAD / HTTP/1.1
> Host: sme62.org
> User-Agent: curl/7.85.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
< Date: Sun, 25 Sep 2022 18:38:37 GMT
Date: Sun, 25 Sep 2022 18:38:37 GMT
< Server: Apache/2.4.6 (CentOS)
Server: Apache/2.4.6 (CentOS)
< X-Powered-By: PHP/7.3.33
X-Powered-By: PHP/7.3.33
< Set-Cookie: PHPSESSID=c9506bad8a889f2782f4b850873254bb; path=/
Set-Cookie: PHPSESSID=c9506bad8a889f2782f4b850873254bb; path=/
< Expires: Thu, 19 Nov 1981 08:52:00 GMT
Expires: Thu, 19 Nov 1981 08:52:00 GMT
< Cache-Control: no-store, no-cache, must-revalidate
Cache-Control: no-store, no-cache, must-revalidate
< Pragma: no-cache
Pragma: no-cache
< Connection: close
Connection: close
< Content-Type: text/html; charset=UTF-8
Content-Type: text/html; charset=UTF-8
<
* Closing connection 0
* TLSv1.2 (IN), TLS alert, close notify (256):
* TLSv1.2 (OUT), TLS alert, close notify (256):
Using PHP to do something the web server should do is also not a very good idea™.
stevewi --
Wow. Head's spinning.
First, I used certbot to get certificates for all this sites except womenofaction.club (because womenofaction.club needs to exist before getting a cert), following instructions (not dreaming up implementation) and in the blink of an eye, I got the cert for them as a group and my vhost.conf file was generated exactly as you see … including port 80. I'm not smart enough to put that there. And all me sites, up to now, enjoy the https security.
(BTW, wheres I have all the current domains under one certificate, I decided I want to create a separate cert for womenofaction.club.)
Second, referring to your take each one of these out of vhosts.conf and put them in files in /etc/apache2/sites-available, is that required or recommended to make it easy to enable/disable?
Third referring to your defined another error log for your problem domain, is that a problem or just an observation. I added that thinking processing of errors would hit the wall without a directory (yea, not folder :) already existing. Should I leave it alone or delete those directories?
Fourth, referring to your comment that certs are domain specific, here's what I get doing a certbot renew dry run:
[ken@alpha /]$ sudo certbot renew --dry-run
[sudo] password for ken:
Saving debug log to /var/log/letsencrypt/letsencrypt.log
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/enfeedia.com.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Cert not due for renewal, but simulating renewal for dry run
Plugins selected: Authenticator apache, Installer apache
Starting new HTTPS connection (1): acme-staging-v02.api.letsencrypt.org
Simulating renewal of an existing certificate for enfeedia.com and 13 more domains
Performing the following challenges:
http-01 challenge for enfeedia.com
http-01 challenge for keligo.com
http-01 challenge for llgorman.com
http-01 challenge for packetstacks.com
http-01 challenge for saddlebrookeranch.org
http-01 challenge for sme62.org
http-01 challenge for storiesofpetsbypetsforpets.com
http-01 challenge for www.enfeedia.com
http-01 challenge for www.keligo.com
http-01 challenge for www.llgorman.com
http-01 challenge for www.packetstacks.com
http-01 challenge for www.saddlebrookeranch.org
http-01 challenge for www.sme62.org
http-01 challenge for www.storiesofpetsbypetsforpets.com
Waiting for verification...
Cleaning up challenges
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
new certificate deployed with reload of apache server; fullchain is
/etc/letsencrypt/live/enfeedia.com/fullchain.pem
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Congratulations, all simulated renewals succeeded:
/etc/letsencrypt/live/enfeedia.com/fullchain.pem (success)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Notice this…
Simulating renewal of an existing certificate for enfeedia.com and 13 more domains
It's like enfeedia.com has some special standing -- I don't know how to say that -- that means enfeedia.com amounts to an envelope for all of the sites. Again, I'm fishing around to try to explain how/why enfeedia.com is king of the hill. I don't recall doing anything special to elevate enfeedia.com to be the "lead". Maybe this is old-hat to everyone reading this, but I'm a novice at this just trying to get alone with SSL.
As to that enfeedia.com.conf, here it is:
# renew_before_expiry = 30 days
version = 1.11.0
archive_dir = /etc/letsencrypt/archive/enfeedia.com
cert = /etc/letsencrypt/live/enfeedia.com/cert.pem
privkey = /etc/letsencrypt/live/enfeedia.com/privkey.pem
chain = /etc/letsencrypt/live/enfeedia.com/chain.pem
fullchain = /etc/letsencrypt/live/enfeedia.com/fullchain.pem
# Options used in the renewal process
[renewalparams]
authenticator = apache
installer = apache
account = 05da2ac33cabf22f97ba4e3654f64ce8
server = https://acme-v02.api.letsencrypt.org/directory
manual_public_ip_logging_ok = None
stevewi --
Wow. Head's spinning.
First, I used certbot to get certificates for all this sites except womenofaction.club (because womenofaction.club needs to exist before getting a cert), following instructions (not dreaming up implementation) and in the blink of an eye, I got the cert for them as a group and my vhost.conf file was generated exactly as you see … including port 80. I'm not smart enough to put that there. And all me sites, up to now, enjoy the https security.
(BTW, wheres I have all the current domains under one certificate, I decided I want to create a separate cert for womenofaction.club.)
Second, referring to your take each one of these out of vhosts.conf and put them in files in /etc/apache2/sites-available, is that required or recommended to make it easy to enable/disable?
Third referring to your defined another error log for your problem domain, is that a problem or just an observation. I added that thinking processing of errors would hit the wall without a directory (yea, not folder :) already existing. Should I leave it alone or delete those directories?
Fourth, referring to your comment that certs are domain specific, here's what I get doing a certbot renew dry run:
[ken@alpha /]$ sudo certbot renew --dry-run
[sudo] password for ken:
Saving debug log to /var/log/letsencrypt/letsencrypt.log
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/enfeedia.com.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Cert not due for renewal, but simulating renewal for dry run
Plugins selected: Authenticator apache, Installer apache
Starting new HTTPS connection (1): acme-staging-v02.api.letsencrypt.org
Simulating renewal of an existing certificate for enfeedia.com and 13 more domains
Performing the following challenges:
http-01 challenge for enfeedia.com
http-01 challenge for keligo.com
http-01 challenge for llgorman.com
http-01 challenge for packetstacks.com
http-01 challenge for saddlebrookeranch.org
http-01 challenge for sme62.org
http-01 challenge for storiesofpetsbypetsforpets.com
http-01 challenge for www.enfeedia.com
http-01 challenge for www.keligo.com
http-01 challenge for www.llgorman.com
http-01 challenge for www.packetstacks.com
http-01 challenge for www.saddlebrookeranch.org
http-01 challenge for www.sme62.org
http-01 challenge for www.storiesofpetsbypetsforpets.com
Waiting for verification...
Cleaning up challenges
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
new certificate deployed with reload of apache server; fullchain is
/etc/letsencrypt/live/enfeedia.com/fullchain.pem
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Congratulations, all simulated renewals succeeded:
/etc/letsencrypt/live/enfeedia.com/fullchain.pem (success)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Notice this…
Simulating renewal of an existing certificate for enfeedia.com and 13 more domains
It's like enfeedia.com has some special standing -- I don't know how to say that -- that means enfeedia.com amounts to an envelope for all of the sites. Again, I'm fishing around to try to explain how/why enfeedia.com is king of the hill. I don't recall doing anything special to elevate enfeedia.com to be the "lead". Maybe this is old-hat to everyone reading this, but I'm a novice at this just trying to get alone with SSL.
As to that enfeedia.com.conf, here it is:
# renew_before_expiry = 30 days
version = 1.11.0
archive_dir = /etc/letsencrypt/archive/enfeedia.com
cert = /etc/letsencrypt/live/enfeedia.com/cert.pem
privkey = /etc/letsencrypt/live/enfeedia.com/privkey.pem
chain = /etc/letsencrypt/live/enfeedia.com/chain.pem
fullchain = /etc/letsencrypt/live/enfeedia.com/fullchain.pem
# Options used in the renewal process
[renewalparams]
authenticator = apache
installer = apache
account = 05da2ac33cabf22f97ba4e3654f64ce8
server = https://acme-v02.api.letsencrypt.org/directory
manual_public_ip_logging_ok = None
I have never used wordpress.
stevewi--
I'll bet this hack is a bad idea: Edit port 80 to be port 443 in all cases. End even if a good idea, how to you explain that as it is, I'm getting the security associated with https.
It's like enfeedia.com has some special standing -- I don't know how to say that -- that means enfeedia.com amounts to an envelope for all of the sites.
It has special standing because you told letsencrypt/certbot that it does.
Processing /etc/letsencrypt/renewal/enfeedia.com.conf
I have never used wordpress.
OK. It was supposition on my part. I'll re-iterate, it's a not a very good idea™ to have PHP do something that the web server should do (much more reliably, efficiently and faster).
As to your immediate problem, I did this to retrieve the cert for womenofaction.club:
stevewi:~ $ openssl s_client -showcerts -connect womenofaction.club:443 < /dev/null
CONNECTED(00000004)
depth=0 C = --, ST = SomeState, L = SomeCity, O = SomeOrganization, OU = SomeOrganizationalUnit, CN = alpha, emailAddress = root@alpha
verify error:num=18:self signed certificate
verify return:1
depth=0 C = --, ST = SomeState, L = SomeCity, O = SomeOrganization, OU = SomeOrganizationalUnit, CN = alpha, emailAddress = root@alpha
verify error:num=10:certificate has expired
notAfter=Jul 23 10:49:43 2021 GMT
verify return:1
depth=0 C = --, ST = SomeState, L = SomeCity, O = SomeOrganization, OU = SomeOrganizationalUnit, CN = alpha, emailAddress = root@alpha
notAfter=Jul 23 10:49:43 2021 GMT
verify return:1
---
Certificate chain
0 s:C = --, ST = SomeState, L = SomeCity, O = SomeOrganization, OU = SomeOrganizationalUnit, CN = alpha, emailAddress = root@alpha
i:C = --, ST = SomeState, L = SomeCity, O = SomeOrganization, OU = SomeOrganizationalUnit, CN = alpha, emailAddress = root@alpha
-----BEGIN CERTIFICATE-----
MIIDzjCCAragAwIBAgICd2owDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNVBAYTAi0t
MRIwEAYDVQQIDAlTb21lU3RhdGUxETAPBgNVBAcMCFNvbWVDaXR5MRkwFwYDVQQK
DBBTb21lT3JnYW5pemF0aW9uMR8wHQYDVQQLDBZTb21lT3JnYW5pemF0aW9uYWxV
bml0MQ4wDAYDVQQDDAVhbHBoYTEZMBcGCSqGSIb3DQEJARYKcm9vdEBhbHBoYTAe
Fw0yMDA3MjMxMDQ5NDNaFw0yMTA3MjMxMDQ5NDNaMIGbMQswCQYDVQQGEwItLTES
MBAGA1UECAwJU29tZVN0YXRlMREwDwYDVQQHDAhTb21lQ2l0eTEZMBcGA1UECgwQ
U29tZU9yZ2FuaXphdGlvbjEfMB0GA1UECwwWU29tZU9yZ2FuaXphdGlvbmFsVW5p
dDEOMAwGA1UEAwwFYWxwaGExGTAXBgkqhkiG9w0BCQEWCnJvb3RAYWxwaGEwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDN2SsAwCr9pipSL/amLGGaeDuq
alDX+vQgREGoKUJDFXtss0BD5WM4cueUcCT4XRPCkUqmEHyuXntiyzkkHgcrdFl/
KawvypQw8+2HTSmJvnwH6B0eD3rlxz+E3qrUsonhCbZWswL3j5tv61xHcvD7gAxl
aWv7vFQYOjYnMhHjvul4ZrmdJEspPqdQUpjhNRLJDZ6AWb8na2hcEY3ENghM7p3Q
q2Au7EcFAV6kyzxfIvjvTxyPBynU5UrUzG0DAWiM148Klqto7LK09qIGdFkcZdQY
vHyVpdaYyEuYA7CBNXKqsqTyai2L4YoFMUm5/wnW4WlVKwBU2VfwMQDgKYtfAgMB
AAGjGjAYMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgXgMA0GCSqGSIb3DQEBCwUAA4IB
AQCU99wQCWttjWq1lqWju8qND5x5TxLSBrx6rjd7eMNg95TyPYFMspkoIz4KeeZJ
QKiI/IsFI6znEttBpePdENXK6c6smabQlRIfYiaiWt0FiI69V6pXJa6YI0K7ZoRE
UFbcztIzsIrJWwF4uG9iAT/QxmahiOyrtFB03C/r0b6HBelRWp/yZhOn5exgAyaj
KRtmVR2QPl2vQKI/XLdu2Mn0cXYbS2V4ayd8Kce6dG8KBdhdNSAX9mYtw8+SPIMI
L0pYE76/yg2eEV/OGck/c5b5+RfyvCSpgaGM/4TgnKw9CmgprKRpU2K894esVlKC
hJCEUWbKwrtjg6fgFfh6q5Aj
-----END CERTIFICATE-----
---
Server certificate
subject=C = --, ST = SomeState, L = SomeCity, O = SomeOrganization, OU = SomeOrganizationalUnit, CN = alpha, emailAddress = root@alpha
issuer=C = --, ST = SomeState, L = SomeCity, O = SomeOrganization, OU = SomeOrganizationalUnit, CN = alpha, emailAddress = root@alpha
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 1680 bytes and written 446 bytes
Verification error: certificate has expired
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: 7B56A8850781E0B1C2CDC799DC7A44093048E4C3584F7AF8CB593F0874F335E4
Session-ID-ctx:
Master-Key: 7225AC0ED13EF34325407B14BDDD5482179C995CAA33BF3E784562D464CFAD8BB8210F064224926D822267E617871953
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - 53 c4 61 b0 f3 28 1e 20-9d 80 36 70 df 71 7c 50 S.a..(. ..6p.q|P
0010 - 84 d6 38 85 01 02 f4 e8-c9 af 42 21 a5 f8 2f f9 ..8.......B!../.
0020 - 15 dd 7b 5f 8e a6 83 f6-96 24 80 38 50 6e 57 02 ..{_.....$.8PnW.
0030 - 17 e0 fa 37 98 d6 f6 ed-fb 50 94 6e ca 70 e5 df ...7.....P.n.p..
0040 - 0c 54 ae e6 94 9c b8 ae-ce ab 84 01 53 b1 e4 3f .T..........S..?
0050 - a4 94 76 2a a2 34 ee 8b-6d ac 9c 73 34 6a c4 34 ..v*.4..m..s4j.4
0060 - b0 ed 36 75 12 c3 bf 63-3d 96 77 67 a9 49 84 4d ..6u...c=.wg.I.M
0070 - fd 52 53 fe b7 a0 30 35-3b 01 7d 24 ce 4b d5 d2 .RS...05;.}$.K..
0080 - df 4a 31 e1 de c9 08 22-87 d0 71 e3 3d 11 d3 45 .J1...."..q.=..E
0090 - 07 13 39 cb 54 1b 3e 45-9a 2a 17 6d 39 b0 05 47 ..9.T.>E.*.m9..G
00a0 - 3b 45 be 90 c1 ab 9c e6-e6 33 c3 cb 35 0a 06 42 ;E.......3..5..B
00b0 - 8d 40 9c ae a9 d6 7d ac-f5 33 09 85 48 1b 65 b3 .@....}..3..H.e.
00c0 - 20 72 50 cb 98 0c 93 39-09 b7 b7 b6 30 fb 1f 1f rP....9....0...
Start Time: 1664132781
Timeout : 7200 (sec)
Verify return code: 10 (certificate has expired)
Extended master secret: no
---
DONE
and verified that this domain is using an expired, self-signed cert. This comports with the previous result from curl. I'll omit the same query for enfeedia.com because it's very long but, suffice to say, it checks out as ok (as do a smattering of other random domains mentioned in this thread). However, that cert does not provide keys for womenofaction.club:
Subject: enfeedia.com
Altnames: DNS:enfeedia.com, DNS:keligo.com, DNS:llgorman.com, DNS:packetstacks.com, DNS:saddlebrookeranch.org, DNS:sme62.org, DNS:storiesofpetsbypetsforpets.com, DNS:www.enfeedia.com, DNS:www.keligo.com, DNS:www.llgorman.com, DNS:www.packetstacks.com, DNS:www.saddlebrookeranch.org, DNS:www.sme62.org, DNS:www.storiesofpetsbypetsforpets.com
I used another tool on a system behind my router to get this info (the tool is not for use on production systems so I'm going to withhold the details about it lest every reader of this post makes their systems insecure by installing it). Note that womenofaction.club is not mentioned as an Altname.
I'll bet this hack is a bad idea: Edit port 80 to be port 443 in all cases.
Worse idea.
And even if a good idea, how to you explain that as it is, I'm getting the security associated with https.
Do you have some apache config that's doing TLS negotiation at some higher level that the vhost? This line:
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
in each of your vhosts establishes a permanent redirect to an https site (perhaps with the SERVER_NAME of enfeedia.com) with the REQUEST_URI of womenofaction.club.
-- sw
P.S. You write:
I used certbot to get certificates for all this sites except womenofaction.club (because womenofaction.club needs to exist before getting a cert), following instructions (not dreaming up implementation) and in the blink of an eye,
You can make http://womenofaction.club exist enough for the Let's Encrypt cert update challenges with the following:
<VirtualHost *:80>
ServerAdmin ken.gorman@me.com
ServerName womenofaction.club
ServerAlias www.womenofaction.club
DocumentRoot /srv/www/womenofaction.club/public_html/
</VirtualHost>
…provided /srv/www/womenofaction.club/public_html/ exists and is owned/readable/writable by the web server.
After the cert has been updated, you can implement the full monty with
<VirtualHost *:80>
ServerAdmin ken.gorman@me.com
ServerName womenofaction.club
ServerAlias www.womenofaction.club
DocumentRoot /srv/www/womenofaction.club/public_html/
ErrorLog /srv/www/womenofaction.club/logs/error.log
CustomLog /srv/www/womenofaction.club/logs/access.log combined
RewriteEngine on
RewriteCond %{SERVER_NAME} =womenofaction.club [OR]
RewriteCond %{SERVER_NAME} =www.womenofaction.club
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>
Maybe the confusion has to do with me striving to get SSL, not TSL. That would explain port 80, right?
I'm reading this:
https://www.ssl2buy.com/wiki/ssl-vs-tls
Why isn't SSL good enough? That ssl2buy.com site doesn't present a truly compelling reason that I must get TSL or that those who got SSL must upgrade to TSL. I don't think people are racing to get TSL because SSL is inadequate. Letsencrypt/certbot is continuing to offer SSL certificates -- that's how I got where I am. I just want one more site to get an SSL certificate. (I'm reconsidering whether to just add it to the current certificate I have.)
SSL provides the one goal I have, to access my sites using https.
The one problem I am having, that stands in the way, is why the VirtualHost block for the womenofaction.club causes all my sites to be inaccessible, when it matches the format of all the existing websites. I see nothing unique to womenofaction.club compared to other sites.
I achieve my goal with the new website getting an SSL certificate and all my sites to be "up".
seven --- YES, I WORKED. I might be repeating a post to say problem solved, but just in case{
You said, You can make http://womenofaction.club exist enough for the Let's Encrypt cert update challenges with the following:**
<VirtualHost *:80>
ServerAdmin ken.gorman@me.com
ServerName womenofaction.club
ServerAlias www.womenofaction.club
DocumentRoot /srv/www/womenofaction.club/public_html/
</VirtualHost>
… and I did. Then you said to do the certbot expand -d and it worked.
I did a dry run, just to see the beauty of the new vhost included.
Then you said do the "full monty", and I did. And it worked.
I had the new website set up with a simple hello world, and browsed to it, and, wow, hello world.
Happy Days Are Here Again!
THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU