Certificate hostname does not match site hostname


#1

My domain is not browser trusted because, my certificate hostnames don’t match my site hostname.

My site hostname is: https://varmlandsk.ordbok.gratis

My certificate hostname is the name of my server in the local net: static-237-143.junet.se

I used:

./letsencrypt-auto certonly --webroot -w /var/www/http/ordbok.gratis/www -d ordbok.gratis -w /var/www/http/varmlandsk.ordbok.gratis/www -d varmlandsk.ordbok.gratis -w /var/www/http/test.varmlandsk.ordbok.gratis/www -d test.varmlandsk.ordbok.gratis

I have mod_vhost_alias enabled

I have a default-ssl.conf-file also

How can I change my certificate hostname to my site hostname?

Regards,
Martin


#2

For some reason, you’ve got a self signed certificate installed. Output from openssl s_client -connect varmlandsk.ordbok.gratis:443 -servername varmlandsk.ordbok.gratis:

Certificate chain
 0 s:/CN=static-237-143.junet.se
   i:/CN=static-237-143.junet.se
 1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X1
   i:/O=Digital Signature Trust Co./CN=DST Root CA X3

That VirtualHost sends the LE intermediate certificate next to your self signed certificate…

ordbok.gratis on the other hand: openssl s_client -connect ordbok.gratis:443 -servername ordbok.gratis

Certificate chain
 0 s:/CN=static-237-143.junet.se
   i:/CN=static-237-143.junet.se

Just the self signed certificate… Same goes for test.varmlandsk.ordbok.gratis

I think your Apache or nginx configuration file isn’t correct…


#3

Thank you for you help.

I think the problem could be that I am using the apache module: mod_vhost_alias, with a single sites-available/vhosts.conf file for all the thousand domains.

The vhosts.conf file only contains

UseCanonicalName Off
VirtualDocumentRoot /var/www/http/%0/www

I could neither find any information in the documentation nor in the community about what configuration file to use, and if letsencrypt at all works with mod_vhost_alias


#4

How did you configure the current (self signed) certificate for static-237-143.junet.se? In default-ssl.conf perhaps? Because somehow one of those hostnames serves the Let’s Encrypt intermediate certificate… So somewhere you’ve made a configuration change I think…

Anyway, the manual page for mod_vhost_alias isn’t saying anything about SSL… And Google also doesn’t give many pages, but perhaps you can find anything in here: http://serverfault.com/questions/390048/how-to-configure-ssl-with-apache2-httpd-mass-virtual-hosting-using-mod-vhost-ali

As I can see, there isn’t an option for SSL with mod_vhost_alias, but what’s suggested is putting the mod_vhost_alias dynamic stuff in a separate <VirtualHost *:80> piece and the SSL-stuff in its own <VirtualHost *:443>, without dynamic virtualhosts… You say you’ve got thousand domains… I hope you don’t have 1000 HTTPS domains, because I haven’t found a way to load the SSL stuff dynamically :stuck_out_tongue:


#5

I think I start to understand things better now.

From the beginning I only had my vhosts.conf file… but I could not complete the certificate installation process with ./letsencrypt-auto

I recieve an error:

ssl_error_rx_record_too_long

So i tried to install an default-ssl.conf file… and I assume that the self signed certificate simply came from this template. So it was a stupid error.

Now I deleted the content in the default-ssl.conf file… and I am back with the original error:

ssl_error_rx_record_too_long

I dont have any intentions to make all thousand domains secure. But I am developing an online dictionary with voice recording features, and I need to make at least one of the domains secure, in order to use the new getUserMedia javascript functions for Chrome and Opera. This only works over a secure connections. And I still need to keep mod_vhost_alias enabled for obvious reasons, because I connot use manually configured conf-files for thousands of server names.


#6

What exactly gives this ssl_error_rx_record_too_long error? Did you do something to cause this? Or did you just ran letsencrypt-auto, after which the error occured?

Obviously to cause a SSL error message, you’ve got to have some sort of SSL configuration directives set up somewhere… So where does the error come from if you’ve deleted the default-ssl.conf file?

From what I can find, that ssl_error_rx_record_too_long error is a Firefox error? Not a server error message? Would be helpful to specify that :wink:


#7

The error came directly after running letsencrypt-auto.

My only conf file then was, vhosts.conf, including the standard:

UseCanonicalName Off
VirtualDocumentRoot /var/www/http/%0/www


#8

Well, at the moment you’ve got Apache listening on port 443 without SSL:

osiris@desktop ~ $ openssl s_client -connect varmlandsk.ordbok.gratis:443 -servername varmlandsk.ordbok.gratis
CONNECTED(00000003)
140434776250000:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:795:
(...)
osiris@desktop ~ $ telnet varmlandsk.ordbok.gratis 443
Trying 146.66.237.143...
Connected to varmlandsk.ordbok.gratis.
Escape character is '^]'.
GET / HTTP/1.1
Host: varmlandsk.ordbok.gratis

HTTP/1.1 200 OK
(...)

Obviously, Apache should do SSL on port 443, not just non-SSL HTTP… So:

Now you should add an <Virtualhost *:443> for your three HTTPS VirtualHosts. (Three separate instances of <VirtualHost *:443>, because you’ve got three webroots…) You could use the Mozilla SSL Configuration Generator for this. Just add the usual ServerName and DocumentRoot stuff also in there, for example, at the point of the first ... part… :slightly_smiling: Please do look at the links after the “See also:” part. Lots of information in the Mozilla TLS Guidelines.


#9

Great… I feel this problem could be about to be solved.

I generated configuration file text, but I simply cannot find any information on the letsencrypt website about which paths that I should use for my certificates and the key… in the configuration file. This is what I have made so far:

<VirtualHost *:443>
    ServerName                  ordbok.gratis
    DocumentRoot                /var/www/https/ordbok.gratis/www
    SSLEngine on
    SSLCertificateFile          /path/to/signed_certificate
    SSLCertificateChainFile     /path/to/intermediate_certificate
    SSLCertificateKeyFile       /path/to/private/key
    SSLCACertificateFile        /path/to/all_ca_certs
</VirtualHost>

<VirtualHost *:443>
    ServerName                  varmlandsk.ordbok.gratis
    DocumentRoot                /var/www/https/varmlandsk.ordbok.gratis/www
    SSLEngine on
    SSLCertificateFile          /path/to/signed_certificate
    SSLCertificateChainFile     /path/to/intermediate_certificate
    SSLCertificateKeyFile       /path/to/private/key
    SSLCACertificateFile        /path/to/all_ca_certs
</VirtualHost>

<VirtualHost *:443>
    ServerName                  test.varmlandsk.ordbok.gratis
    DocumentRoot                /var/www/https/test.varmlandsk.ordbok.gratis/www
    SSLEngine on
    SSLCertificateFile          /path/to/signed_certificate
    SSLCertificateChainFile     /path/to/intermediate_certificate
    SSLCertificateKeyFile       /path/to/private/key
    SSLCACertificateFile        /path/to/all_ca_certs
</VirtualHost>

#10

You should look in the /etc/letsencrypt/live directory. You’ll probably find one directory: the first domain you specified with -d on the initial command line invocation of the LE client. That’s probably ordbok.gratis when I look at your first post in this thread.

Did you correctly set all the version numbers of the software in the generator? I.e., you’ve got an Apache version below 2.4.8? If that is indeed the case, you should point SSLCertificateFile to the cert.pem you’ve found in /etc/letsencrypt/live/yoursubdomain/, SSLCertificateChainFile to chain.pem and SSLCertificateKeyFile to privkey.pem. If you won’t be doing any client certificate authentication (which probably is the case), you can delete SSLCACertificateFile.

As you’ve generated one certificate for all three domains, you can just repeat the same SSLCertificate... directives (i.e.: with the same file names), because this one certificate is valid for all domains.

By the way: I see you didn’t adopted the SSLProtocol parts of the Mozilla SSL Generator? And also not the OCSP part (if your Apache is recent enough that is, otherwise the generator won’t show it anyway…) Is this on purpose? It’s probably wise to enter your used version number of Apache and OpenSSL, choose one of the “Modern”, “Intermediate” or “Old” compatibility settings (you can see the supported OS and browser versions change if you change the compatibility setting on the fly) and take over the SSLProtocol and SSLCipherSuite parts… SSLHonorCipherOrder on is always a good thing.


#11

Thank you

I entered the versions of apache2 and openssl, and I entered the generated SSLProtocol part in the conf file. But I dit not want to enter this information here.


#12

No problem. :slightly_smiling: (Isn’t sensitive configuration information though) Don’t forget to test your domains with a SSL tester like SSLLabs and/or HT Bridge! :slightly_smiling:


#13

YES!

Great… it works. Now I can use getUserMedia… and I dont have to learn Flash-programming. So, this can well have saved me a couple of weeks of labour ha ha…

I hade to make a https and non-punycode version of http://värmländsk.ordbok.gratis in order to be able to use getUserMedia

Have a nice weekend!