Supplied wrong domain names (?) - vhost setup apache

I installed certbot-auto on CENTOS 6 with apache succesfully.

I ran certbot-auto for a virtual host referring to two domains.

Certbot issued one warning “we were unable to set up enhancement redirect for your server, however, we successfully installed your certificate”. Indeed, http does not redirect. But that’s not the issue here.

The real problem is that SSL / https fails:

The test result …
gives …
"Certificate name mismatch"
and my browser says …
“Your connection is not secure”.

This is the command I gave:
certbot-auto --apache -d -d

And this is in the vhost configuration file (that worked perfect with http):
ServerAlias * *
DocumentRoot /var/www/

The certificates are stored under …/…

What is the problem?
If I specified the wrong domain names with certbot, what should I have specified?
If my vhost configuration is the trouble, what should be in the conf file?
What can I do to fix this?

And … sorry for my ignorance. I have been reading all kinds of documents the last two weeks to get this working smoothly, and nevertheless I failed :frowning:
Thanks a lot for your help!!

It looks as if you obtained a certificate, but your apache is still using a self signed certificate.

It may be that you just need to restart apache.

If that doesn’t work, can you access the /etc/httpd directory, and then check in the config which SSL derts are being used ( grep -R SSLCertificate * ) they should be ones in /etc/letsencrypt/live/…

  1. Restarting apache does not make any difference.
  2. The SSLCertificate specified in the conf file does exist in /etc/letsencrypt/live/
    (note: there is also a ssl.conf and it points to SSLCertificateFile and SSLCertificateKeyFile)

I did more tests with …

and it turns out that the test complains about the vps domain name:

Fingerprint SHA1: 49735438478cb015afea30f9fd3537dfa472d301
Pin SHA256: bg7a3+/CVs+JfBIjVu+yP498poQIrgwCL5nyHkCXt9g=
Common names MISMATCH
Alternative names -
Valid from Thu, 10 Nov 2016 19:07:14 UTC
Valid until Fri, 10 Nov 2017 19:07:14 UTC (expires in 11 months and 30 days)
Key RSA 2048 bits (e 65537)
Weak key (Debian) No
Issuer Self-signed
Signature algorithm SHA256withRSA
Extended Validation No
Certificate Transparency No
OCSP Must Staple No
Revocation information None
Trusted No NOT TRUSTED (Why?)

So, does this mean that the server is using a “self signed certificate”?

If so, I hope you can give me a suggestion on how to fix this.

I forgot: the test also returns this reason

Certification Paths

Path #1: Not trusted (path does not chain to a trusted anchor)
Sent by server
Not in trust store Self-signed
Fingerprint SHA1: 49735438478cb015afea30f9fd3537dfa472d301
Pin SHA256: bg7a3+/CVs+JfBIjVu+yP498poQIrgwCL5nyHkCXt9g=
RSA 2048 bits (e 65537) / SHA256withRSA


Id suggest confirming https:// setup …

The site responds via http:// but https:// for me responds with the default apache site.
Even if the ssl cert is mismatched… I would normally expect to see your site (same as http)… but with the browser complaining it is an invalid certificate.

In this case, https:// gives me basically a non-existent site – and hence yields the default hosters ssl cert

What files have you got in /etc/letsencrypt/live/ ? is the certificate in there somewhere ? if not, what folders are in /etc/letsencrypt/live/ ? is there a folder there in which the certificate exists ?

Sorry, but I do not quite understand your “confirming https:// setup …”.

So the problem is the self signed VPS cert for, right?

I do not know how to fix it.

Should I expand the list of domains for the certificate, e.g.
$ certbot-auto --apache -d -d -d

And if so, how can I create a new certificate for other domains running on the same VPS server? Imo this will create a conflict again with the VPS server. Or should I use one cert for all domains?

(Our posts crossed!!)

Yes, the certificate is there:

I’ve got four symbolic links:

And they point to certs on

The apache conf.d contains two conf files
One for *:.80 without redirecting to https
One create by certbot for *:443 pointing to the above mentioned certs


This shouldn't be necessary - unless you actually use your vps ndomain name for anyone connecting.

You shouldn't need to create a new cert - you already have one for and (unless you use / redirect from and ... in which case you may need to expand your certificate to include those).

The "symbolic links" in ../ are the files you need.

If the file created by certbot for *:443 links to those files, then it should be all OK .... Does the config also point to the VPS config files somewhere ? Are you happy to paste your apache config files in ?

Well, it seems most likely that this Apache configuration does not, in fact, control the web server the tests are connecting to, since that server is providing instead a completely different certificate.

You wrote already that you tried restarting Apache, so that's not it. Is it possible you have some other server software, such as a "reverse proxy", a load balancer or similar that answer the HTTPS connection ?

The ssl conf:

The original conf file:

(Hope I embed this correctly?)

I have no idea. It's a fact however that I cannot use sendmail for the same reason: when I send a mail, the VPS adds the domain as the sender and the mail is consequently rejected by gmail and other mail providers.


It looks to be missing a few important lines. The key one being “SSLEngine on”

have a look at ( and select the version of your apache, and if you want to support just the latest browsers, or a wider range).

These files don’t include your VPS cert - I’m guessing there is another file (default-ssl.conf ? ) with that in.

hopefully just adding “SSLEngine on” and then reloading apache should get you working ( it does depend slightly what’s in your other config file though - as to which one it’s using )

Yep. SSLEngine on is already in ssl.conf, among some other setup things
Adding it to the does not make any difference

can you paste the ssl.conf in pastebin ? I’m assuming that’s the file it’s using rather than the domain specific one you pasted.

Alternatively, just disable the ssl.conf one for now, reload apache and test

Thanks. That’s the file it seems to be using - but should also be using the other file for the domain ( from the settings you have there ).

Can you double check from the processes that it is reloading the updated config properly ( there isn’t an old apache process continuing to run. maybe stop apache completely - confirm it’s stopped and then restart ).

also, does “apachectl -t” (which tests the apache config ) confirm everything is OK.

done, (checked with ps -ef | grep http)

done, everything OK

When starting apache (httpd), should ssl.conf be processed before the vhost conf files?

I’m not sure on the “before”, but they shouldn’t conflict, as it should take the correct config for the specific domain ( )

One difference to my typical configs is the order of the “IfModule” statement shich seems odd in yours. Assuming you have the module though it shouldn’t make a difference.

<VirtualHost *:443>
        DocumentRoot /var/www/domain/

        ErrorLog /var/log/apache/error.log

        <IfModule mod_ssl.c>
        SSLEngine on
        SSLProtocol All -SSLv2 -SSLv3
        SSLCertificateFile /path/to/cert
        SSLCertificateKeyFile /path/to/key
        SSLCACertificateFile /path/to/chain


I get different browser warnings now, meaning that the SSL connection is not working at all:

An error occurred during a connection to SSL received a record that exceeded the maximum permissible length. Error code: SSL_ERROR_RX_RECORD_TOO_LONG

Ssllabs says:

Assessment failed: No secure protocols supported