Seems like domain is pointing to wrong machine to get my certificates when using SSL

My domain is:

I ran this command in my browser:

It produced this output:
The connection is not private warning

I ran this command:

on an ssl test site:

It produced this output:
Untrusted Reasons The certificate doesn’t match hostname Common Name Key Type/Size RSA 2048 bits Signature Algorithm sha256WithRSAEncryption Subject Alternative Names, Transparency Yes Validation Level DV CRL http://ocsps.ssl.comOCSP Must-Staple No Supports OCSP Stapling No Valid From November 25th 2018, 14:36 CET Valid To September 1st 2019, 15:36 CEST
My web server is (include version):
Server version: Apache/2.4.38 (Unix)
Server built: Feb 10 2019 02:48:38

The operating system my web server runs on is (include version):
Mac OS 10.14.2

I can login to a root shell on my machine (yes or no, or I don’t know):

I’m using a control panel to manage my site (no, or provide the name and version of the control panel):

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot):
certbot 0.32.0

certbot certificates on

Found the following certs:
Certificate Name:
Expiry Date: 2019-06-10 03:00:20+00:00 (VALID: 89 days)
Certificate Path: /etc/letsencrypt/live/
Private Key Path: /etc/letsencrypt/live/
Certificate Name:
Expiry Date: 2019-06-09 22:52:36+00:00 (VALID: 88 days)
Certificate Path: /etc/letsencrypt/live/
Private Key Path: /etc/letsencrypt/live/
Certificate Name:
Expiry Date: 2019-06-08 22:49:40+00:00 (VALID: 87 days)
Certificate Path: /etc/letsencrypt/live/
Private Key Path: /etc/letsencrypt/live/

Hi @netbrackets,

Is this service meant to be accessible to the public? I tried to access it via your link, but I got a connection refused (distinct from the error that you reported above).

Hi @shoen,
Sorry, I was mucking with it, it should be operational now. However, NOW it seems to be working. I’ve been working on the error for 4 hours at least, and now it starts to work. No idea what I did except restart apache for the umpteenth time.

However when I use the test site I still get an error on the test site which gives me pause:

However when I try it here:

It says all is good.

After refreshing the test:
seems OK; now with A- result.

Wow, now that test is working for me too. Is there a trick to refreshing it? I just put the URL in and clicked the right arrow for the last two hours today and got errors every time.

Anyway it was acting very strange picking up a certificate that wasn’t even loaded on that machine, it’s on another one. I have not changed the domain A record in days.

I don’t know about this particular scanner, but some of the online testing tools do cache their results and don’t re-perform the test automatically when you ask about the same site later on.

Now I’m trying to add another domain ( but can’t get it to work. I’ve successfully created the keys

In httpd.conf I have:
Include /usr/local/etc/httpd/extra/httpd-vhosts-le-ssl.conf

in extra/httpd-vhosts-le-ssl.conf I have:
<IfModule mod_ssl.c>

<VirtualHost *:8443>

DocumentRoot “/Library/WebServer/Documents”



SSLCertificateFile “/etc/letsencrypt/live/”

SSLCertificateKeyFile “/etc/letsencrypt/live/”

ErrorLog “/usr/local/var/log/httpd/error_log”

TransferLog “/usr/local/var/log/httpd/access_log”



certbot certificats:
Certificate Name:
Expiry Date: 2019-06-10 03:00:20+00:00 (VALID: 89 days)
Certificate Path: /etc/letsencrypt/live/
Private Key Path: /etc/letsencrypt/live/

You shouldn’t include the port in the name - it is already controlled by the virtualhost setting.

Updated to below, but still no go.

<VirtualHost *:8443>

General setup for the virtual host

DocumentRoot “/Library/WebServer/Documents”



SSLCertificateFile “/etc/letsencrypt/live/”

SSLCertificateKeyFile “/etc/letsencrypt/live/”

ErrorLog “/usr/local/var/log/httpd/error_log”

TransferLog “/usr/local/var/log/httpd/access_log”



The name resolves to IPv4 & IPv6 addresses:
Addresses: fe80::462:629a:593e:bd5a
This vhost config may not cover both:

A check on 6 shows:
curl -Iki6
curl: (7) Couldn't connect to server

the 4 address seems to just timeout (eventually)

EDIT: Sorry that 4 was my firewall blocking the outbound request on port 8443.
It seems to connect but shows the “wrong cert”:
[using: openssl s_client -connect -servername]

Yeah, the certbot wouldn’t create a certificate until after I added the ipv6 address for this domain, even though it made the other certs fine without it on their domains. Should I remove the ipv6 IP from that domain? Would I need to re-make the cert if I do?

You don’t need to recreate the certificate if you have a valid one; the certificate doesn’t mention any IP addresses at all, only domain names.

If you advertise an IPv6 address in DNS, your server has to actually listen in IPv6. It looks like currently you do advertise an IPv6 address with an AAAA record, but your server isn’t currently reachable that way.

How can you tell it’s the wrong cert? I think I’ll delete the ipv6 AAAA record from that domain since non of my other domains have it.

And is that fairly common to block port 8443? I would think that would be better since it’s an encryption port.

Adding the IPv6 “just to get a cert” really makes no sense to me.
I don’t even know how to comment on that…
Other than if you don’t need it, then don’t use it.
[but you kind of just said that you do need it…]

Ha, me either. Maybe it was coincidence, but I tried and tried to create a cert for that domain and kept getting errors (sadly I can’t remember exactly what it was). I then added the record, and it worked. Strange things seem to be occurring all around on this machine

It could be that you had a firewall blocking some connections to the IPv4 address but not corresponding connections to the IPv6 address, for example. (I don’t have any evidence of this, but that’s just an example of why adding an IPv6 address might make something work that failed in IPv4.)

Moving the definition into my main httpd-ssl.conf file didn’t help. Gotta be something wrong with the vhost config.

maybe the file isn’t being included.
ls -l /etc/apache2/sites-enabled/
as compared to:
ls -l /etc/apache2/sites-available/

My apache is installed by Homebrew at:


I don’t see any dirs like that there.

perhaps there is a /conf.d/ or the likes

Be sure that the inclusion search (like *.conf) matches that file name.