CERT-BOT / SSL on Apache V2.4 with multiple domains


Please fill out the fields below so we can help you better.

My domain is: (www.)wees.de www.fw-wees.de

I ran this command: certbot certonly -d www.wees.de, netoffice.wees.de, wees.de

It produced this output:

My operating system is (include version): Arch Linux

My web server is (include version): Apache 2.4.25 (built 2016-12-12)

My hosting provider, if applicable, is: NA

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

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

I seem to succeed on creating the certificates and they look ok. My problem is, that I seem to fail to deploy the fullchain etc into the virtual hosts!

Certbot told me:

Generating key (2048 bits): /etc/letsencrypt/keys/0009_key-certbot.pem
Creating CSR: /etc/letsencrypt/csr/0009_csr-certbot.pem

 - Congratulations! Your certificate and chain have been saved at
   /etc/letsencrypt/live/wees.de/fullchain.pem. Your cert will expire
   on 2017-06-08. To obtain a new or tweaked version of this
   certificate in the future, simply run certbot again. To
   non-interactively renew *all* of your certificates, run "certbot

Inside the virtualhost container I wrote:

<virtualhost _default_:443>
    ServerName www.wees.de:443
    serverAlias wees.de:443 www.wees.de:443
    ....(skipped out the paths) ...
    SSLEngine on
    SSLCertificateFile "/etc/letsencrypt/live/wees.de/fullchain.pem"
    SSLCertificateKeyFile "/etc/letsencrypt/keys/0009_key-certbot.pem"

Everything seems ok and Apache launches smoothly - But then the Browser tells me:

`www.wees.de uses an invalid security certificate.

The certificate is only valid for www.sippe-oldebusch.de

What did I do wrong? Why is the cert pointing to an other domain name?


Well, when I actually surf to https://www.wees.de, I get the “Sippenverband Harm und Hille Oldebusch” site. And I’m guessing that’s not the intended site you want to show for www.wees.de :wink:

Therefore, I think the problem lies with your <VirtualHost> itself. My personal “best practices” when it comes to Apache is "always use the capitalisation the Apache documentation uses too. So not <virtualhost>, but <VirtualHost>. Probably not the reason why it isn’t working, but can’t harm :wink:

Secondly, I personally have never used ports (:443) in a ServerName (or ServerAlias) directive. While it seems to be valid according to the docs, they also say it’s mostly for funky applications when the server is behind a reverse proxy or load balancer. So I would suggest just using ServerName www.wees.de (and corresponding ServerAlias wees.de of course).

Thirdly: is the new <VirtualHost> section loaded at all? As in, is it in a separate file? Or did you put it in an existing file? Perhaps Apache doesn’t load the section at all! Who knows…

Fourthly: I would suggest using /etc/letsencrypt/live/wees.de/privkey.pem as the private key. The files in /keys/ are for internal use only and the next time you renew your certificate, 0009_key-certbot.pem will be invalid. The files in /live/ on the other hand are symbolic links to the files in /archive/ and always point to the most recent certificate/fullchain/private key.


Okay … let us take a closer look.


Virtual hosts

Include conf/extra/httpd-vhosts.conf


get all other vhosts

Include conf/vhosts/*.conf

so … all domains have their own file and there in fact is a sippe-oldebusch domain in the configs.

it holds this config:

ServerName www.sippe-oldebusch.de
ServerAlias sippe-oldebusch.de
ServerAdmin hansen@xxxxxxxx.yyy
ScriptAlias /cgi-bin/ /somewhere/sippe-oldebusch.de/cgi-bin/
DocumentRoot /somewhere/sippe-oldebusch.de/docs
ErrorLog /somewhere/sippe-oldebusch.de/logs/error.log
CustomLog /somewhere/sippe-oldebusch.de/logs/access.log common

    <Directory /somewhere/sippe-oldebusch.de/docs>
      Options +FollowSymLinks +Includes
      AllowOverride All
      Require all granted
   <Directory  /somewhere/sippe-oldebusch.de/cgi-bin>
      Options +FollowSymLinks +Includes +ExecCGI
      AllowOverride All
      Require all granted
   SSLEngine on
   SSLCertificateFile "/etc/letsencrypt/live/www.sippe-oldebusch.de/fullchain.pem"
   SSLCertificateKeyFile "/etc/letsencrypt/keys/0004_key-certbot.pem

Next we have the one for wees.de:

ServerAdmin support@ahp-gmbh.de
ServerName www.wees.de
serverAlias wees.de
ScriptAlias /cgi-bin/ /somewhere/wees.de/cgi-bin/
DocumentRoot /somewhere/wees.de/docs/
ErrorLog /somewhere/wees.de/logs/error.log
CustomLog /somewhere/wees.de/logs/access.log common

    <Directory /somewhere/wees.de/docs>
      Options +FollowSymLinks +Includes
      AllowOverride All
      Require all granted

    <Directory  /somewhere/wees.de/cgi-bin>
      Options +FollowSymLinks +Includes +ExecCGI
      AllowOverride All
      Require all granted

    SSLEngine on
    SSLCertificateFile "/etc/letsencrypt/live/wees.de/fullchain.pem"
   #SSLCertificateKeyFile "/etc/letsencrypt/keys/0009_key-certbot.pem"
    SSLCertificateKeyFile "/etc/letsencrypt/live/wees.de/privkey.pem"

(after typing all the above stuff … FOUND IT!)

The problem seeams to be the “default” which doesn’t work as I would have assumed! I corrected it to the domain ( www.wees.de ) and then everything did well!

Thank you so much for your time and thoughts @Osiris


Glad you got things working!

Might I suggest to, unless you’re using IP based virtual hosting (when every Virtualhost has its own IP address… Quite uncommon nowadays with IPv4 address shortages), to use the format <VirtualHost *:port>. For example, for all non-HTTPS virtualhosts: <VirtualHost *:80> and for all HTTPS virtualhosts use <VirtualHost *:443>. If all configuration files follow that syntax, you won’t have any trouble at all, even in the future.
Of course it’s up to you if you want to leave it like you have now (it’s working after all) or want to try out the above :slight_smile:


sure thing … I guess, that’s what I wanted to archive.

Have a nice weekend and once again: Thanks :slight_smile:


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.