Apache2 vhosts domain and subdomain certificate problems


#1

Domain: acegames.de

OS: Linux vserver 2.6.32-042stab116.2 + debian-8.0-amd64-owncloud

Web-Server: Apache2 (I use vHosts to point my subdomains to different locations on the server)

Hosting-Provider: Kramer Betriebs GmbH (Prepaid-Hoster.de)

SSH: ssh connection via putty works perfectly (no controlpanels)

vHost info:
default-vhost: acegames.de (/var/www/html/) and its alias www.acegames.de
second-vhost: status.acegames.de (var/www/html/status/)
third-vhost: cloud.acegames.de (/var/www/owncloud/)

The Story behind it:

If i do the following command: certbot-auto --apache -d -acegames.de -d www.acegames.de
Output is: no errors! has been created.
If i test it, the ony-https works for both (acegames.de and www.acegames.de) but chrome outputs, that the certificate that is used here (www.acegames.de) is ony for acegames.de

[There are issues with the site’s certificate chain (net::ERR_CERT_COMMON_NAME_INVALID).]

then if i do: certbot-auto --apache -d cloud.acegames.de
i get:

Failed authorization procedure. cloud.acegames.de (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Failed to connect to 137.74.140.78:443 for TLS-SNI-01 challenge.

IMPORTANT NOTES:

  • The following errors were reported by the server:

Domain: cloud.acegames.de
Type: connection
Detail: Failed to connect to 137.74.140.78:443 for TLS-SNI-01
challenge

To fix these errors, please make sure that your domain name was
entered correctly and the DNS A record(s) for that domain
contain(s) the right IP address. Additionally, please check that
your computer has a publicly routable IP address and that no
firewalls are preventing the server from communicating with the
client. If you’re using the webroot plugin, you should also verify
that you are serving files from the webroot path you provided.

But i have checked the DNS-Records of acegames.de and theres everything right.
if a certificate has already been made for acegames.de it reports, that there already is a cert for acegames.de

And if i do both in one its getting even more crazy:
certbot-auto --apache -d acegames.de -d www.acegames.de -d cloud.acegames.de
or certbot-auto --apache -d acegames.de -d www.acegames.de -d status.acegames.de (doesnt matter which…)

output:

Failed authorization procedure. cloud.acegames.de (tls-sni-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Incorrect validation certificate for TLS-SNI-01 challenge. Requested 5f0fbb61f0a40da088bd1ddd42e0a61b.791f2107b9946e40865ec0855b7a1ed0.acme.invalid from 137.74.140.78:443. Received certificate containing ‘dummy, 059f15b2f20053caf0b3f4bbe4f69485.d8267e5a91003c860c27163b540acf29.acme.invalid’

IMPORTANT NOTES:

  • The following errors were reported by the server:

Domain: cloud.acegames.de
Type: unauthorized
Detail: Incorrect validation certificate for TLS-SNI-01 challenge.
Requested
5f0fbb61f0a40da088bd1ddd42e0a61b.791f2107b9946e40865ec0855b7a1ed0.acme.invalid
from 137.74.140.78:443. Received certificate containing ‘dummy,
059f15b2f20053caf0b3f4bbe4f69485.d8267e5a91003c860c27163b540acf29.acme.invalid’

To fix these errors, please make sure that your domain name was
entered correctly and the DNS A record(s) for that domain
contain(s) the right IP address.

i am really confused.


Letsencrypt certificates unable to update after created a second cert (called the same way)
#2

It looks as if you have a number of different issues here, can I suggest they are worked through one at a time.

  1. Your certificate fors for acegames.de / www.acegames.de These appear to be for only one domain, or the other - not both. You can see the issued certificates at https://crt.sh/?q=%acegames.de

I assume you used

sudo apt-get install python-certbot-apache -t jessie-backports

to install certbot on your debian 8 - correct ?

If you run

certbot --apache -vvvv -d -acegames.de -d www.acegames.de

this should give a verbose log of what is happening, can you paste that in pastebin.com and provide a link please.

Your cloud. and status. subdomains seeem to be a different error, but let’s start with the one above.


#3

Soo… it seems like a wonder but today i tryed the acegames.de and www.acegames.de cert again.
after i had “reloaded” the packets via

and used

$ rm -r /usr/local/sbin/certbot-auto
$ cd /usr/local/sbin
$ wget https://dl.eff.org/certbot-auto
$ certbot-auto --apache -d acegames.de -d www.acegames.de

instead of your

which doesnt work.

And the magic is that now both sites are available via https-only and no cert errors appear.

I’ll test the others too…


#4

Ok, so your certificate now includes both domain names

DNS Name: acegames.de
DNS Name: www.acegames.de

so that’s working as expected. - good :slight_smile:


#5

$ certbot-auto --apache -d acegames.de -d www.acegames.de -d status.acegames.de

lqqqqqqqqqqqqqqqqqqqqqqqq
x Saving debug log to /var/log/letsencrypt/letsencrypt.log
x Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
x Obtaining a new certificate
x Performing the following challenges:
x tls-sni-01 challenge for acegames.de
x tls-sni-01 challenge for www.acegames.de
x tls-sni-01 challenge for status.acegames.de
x Waiting for verification…
x Cleaning up challenges
mqqqqqqqqqqqqqqqqqqqqqq

Failed authorization procedure. status.acegames.de (tls-sni-01): urn:acme:error:unauthorized :: The client lacks
sufficient authorization :: Incorrect validation certificate for TLS-SNI-01 challenge. Requested
cbc848356e6910dcf8449dbba6c5acb6.1dbcf1f1cbbd922878d7e8ba5cac1182.acme.invalid from 137.74.140.78:443.
Received certificate containing ‘dummy,
059f15b2f20053caf0b3f4bbe4f69485.d8267e5a91003c860c27163b540acf29.acme.invalid’

IMPORTANT NOTES:

  • The following errors were reported by the server:

Domain: status.acegames.de
Type: unauthorized
Detail: Incorrect validation certificate for TLS-SNI-01 challenge.
Requested
cbc848356e6910dcf8449dbba6c5acb6.1dbcf1f1cbbd922878d7e8ba5cac1182.acme.invalid
from 137.74.140.78:443. Received certificate containing ‘dummy,
059f15b2f20053caf0b3f4bbe4f69485.d8267e5a91003c860c27163b540acf29.acme.invalid’

To fix these errors, please make sure that your domain name was
entered correctly and the DNS A record(s) for that domain
contain(s) the right IP address.

jep…looks bad for the magic.

/var/log/letsencrypt/letsencrypt.log:

http://download.acegames.de/lets-log.txt


#6

It looks as if you have an invalid config in apache for status.acegames.de - it’s using http there, not https ( you can check this by going to http://status.acegames.de:443 and you will get a http response - not a https response )

You should check your apache config for the subdomains.


#7

/etc/apache2/sites-available/000-default.conf

# The ServerName directive sets the request scheme, hostname and port that # the server uses to identify itself. This is used when creating # redirection URLs. In the context of virtual hosts, the ServerName # specifies what hostname must appear in the request's Host: header to # match this virtual host. For the default virtual host (this file) this # value is not decisive as it is used as a last resort host regardless. # However, you must set it for any further virtual host explicitly. ServerName http://acegames.de

ServerAdmin webmaster@localhost
DocumentRoot /var/www/html
ServerAlias www.acegames.de

Available loglevels: trace8, …, trace1, debug, info, notice, warn,

error, crit, alert, emerg.

It is also possible to configure the loglevel for particular

modules, e.g.

#LogLevel info ssl:warn

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined

For most configuration files from conf-available/, which are

enabled or disabled at a global level, it is possible to

include a line for only one particular virtual host. For example the

following line enables the CGI configuration for this host only

after it has been globally disabled with “a2disconf”.

#Include conf-available/serve-cgi-bin.conf
RewriteEngine on
RewriteCond %{SERVER_NAME} =www.acegames.de [OR]
RewriteCond %{SERVER_NAME} =acegames.de
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,QSA,R=permanent]

/etc/apache2/sites-available/003-status.acegames.de.conf

# The ServerName directive sets the request scheme, hostname and port that # the server uses to identify itself. This is used when creating # redirection URLs. In the context of virtual hosts, the ServerName # specifies what hostname must appear in the request's Host: header to # match this virtual host. For the default virtual host (this file) this # value is not decisive as it is used as a last resort host regardless. # However, you must set it for any further virtual host explicitly. ServerName http://status.acegames.de

ServerAdmin webmaster@localhost
DocumentRoot /var/www/html/status

Available loglevels: trace8, …, trace1, debug, info, notice, warn,

error, crit, alert, emerg.

It is also possible to configure the loglevel for particular

modules, e.g.

#LogLevel info ssl:warn

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined

For most configuration files from conf-available/, which are

enabled or disabled at a global level, it is possible to

include a line for only one particular virtual host. For example the

following line enables the CGI configuration for this host only

after it has been globally disabled with “a2disconf”.

#Include conf-available/serve-cgi-bin.conf

hm… seems like i’ve forgotten about the http-to-https-rewriter i built in a few months ago


#8

hm… but the error hasnt gone away.
the ony thing that happens is that now http is automaticly rewritten to https but there is no certificate, because the error when creating it for something other than/and acegames.de/www.acegames.de remains.

ERR_SSL_PROTOCOL_ERROR
when i try to load one of my sites in chrome.

I was just thinking of the 000-default-le-ssl.conf wich is created when creating a cert… please correct me if im wrong but isnt this the ssl configuration only for acegames.de and www.acegames.de (000-default.conf)? So should it create files like this for 003-status.acegames.de.conf too? i dont really know where the error when creating a cert for any other than acegames.de/www.acegames.de comes from but it seems a bit suspicious to me that it is called that way and what is written in it. What about copying and testing if a 003-status.acegames.de-le-ssl.conf will have a positive effect on creating a cert for it.


#9

That depends what “it” is :wink:

The default file “000-default.conf” is usually what it says - the default. i.e. what would be used for all domains, if it’s not over-ridden by another file.

The naming of 003-status.acegames.de.conf sounds as if you have a control panel / configuration manager of some sort ( people don’t usually add numbers to their configs, hence I’m guessing that you didn’t name / create that file yourself). if so then that control panel / configuration manager could create the SSL config - if you tell it to. If not then you need to create the config ( or turn off the forwarding (http to https) for those subdomians.


Trouble setting up Apache2 with CertBot
#10

sorry i meant I not it :joy:
these are my selfwritten vhost files… the number at the front of the name is only for me to help me searching and to make the autofill in putty easier

status.acegames.de is the same as this letsencrypt.status.io site in a more simple way

this 000-default-le-ssl.conf was automaticly generated by certbot-auto.
and i wondered if it could help when i create one for (for example) status.acegames.de and try the certificate-creation again. because of the fact that tis file manages parts of the ssl.


#11

Ok, makes sense :slight_smile:

You either need to remove the redirect to https for all domains ( temporarily for now - this is probably the easiest option ) or add a self signed cert and configure https for the subdomain.


#12

Removed the Rewrite-Engine in every vhost and commented out in one.

But this is interesting too:

/etc/apache2/sites-available/default-ssl.conf

[IfModule mod_ssl.c]
[VirtualHost default:443]
ServerAdmin webmaster@localhost

  DocumentRoot /var/www/html
  #LogLevel info ssl:warn
  ErrorLog ${APACHE_LOG_DIR}/error.log
  CustomLog ${APACHE_LOG_DIR}/access.log combined
  #Include conf-available/serve-cgi-bin.conf
  #   SSL Engine Switch:
  #   Enable/Disable SSL for this virtual host.
  SSLEngine on
  SSLCertificateFile	/etc/letsencrypt/live/acegames.de/cert.pem
  SSLCertificateKeyFile /etc/letsencrypt/live/acegames/privkey.pem
  #SSLCertificateChainFile /etc/letsencrypt/live/acegames.de/chain.pem
  #   Certificate Authority (CA):
  #SSLCACertificatePath /etc/ssl/certs/
  #SSLCACertificateFile /etc/apache2/ssl.crt/ca-bundle.crt
  #   Certificate Revocation Lists (CRL):
  #SSLCARevocationPath /etc/apache2/ssl.crl/
  #SSLCARevocationFile /etc/apache2/ssl.crl/ca-bundle.crl
  #   Client Authentication (Type):
  #SSLVerifyClient require
  #SSLVerifyDepth  10
  #   SSL Engine Options:
  #   Set various options for the SSL engine.
  #   o FakeBasicAuth:
  #	 Translate the client X.509 into a Basic Authorisation.  This means that
  #	 the standard Auth/DBMAuth methods can be used for access control.  The
  #	 user name is the `one line' version of the client's X.509 certificate.
  #	 Note that no password is obtained from the user. Every entry in the user
  #	 file needs this password: `xxj31ZMTZzkVA'.
  #   o ExportCertData:
  #	 This exports two additional environment variables: SSL_CLIENT_CERT and
  #	 SSL_SERVER_CERT. These contain the PEM-encoded certificates of the
  #	 server (always existing) and the client (only existing when client
  #	 authentication is used). This can be used to import the certificates
  #	 into CGI scripts.
  #   o StdEnvVars:
  #	 This exports the standard SSL/TLS related `SSL_*' environment variables.
  #	 Per default this exportation is switched off for performance reasons,
  #	 because the extraction step is an expensive operation and is usually
  #	 useless for serving static content. So one usually enables the
  #	 exportation for CGI and SSI requests only.
  #   o OptRenegotiate:
  #	 This enables optimized SSL connection renegotiation handling when SSL
  #	 directives are used in per-directory context.
  #SSLOptions +FakeBasicAuth +ExportCertData +StrictRequire
  [FilesMatch "\.(cgi|shtml|phtml|php)$"] 
  		SSLOptions +StdEnvVars
  [/FilesMatch] 
  [Directory /usr/lib/cgi-bin] 
  		SSLOptions +StdEnvVars
  [/Directory] 
  #   SSL Protocol Adjustments:
  #   The safe and default but still SSL/TLS standard compliant shutdown
  #   approach is that mod_ssl sends the close notify alert but doesn't wait for
  #   the close notify alert from client. When you need a different shutdown
  #   approach you can use one of the following variables:
  #   o ssl-unclean-shutdown:
  #	 This forces an unclean shutdown when the connection is closed, i.e. no
  #	 SSL close notify alert is send or allowed to received.  This violates
  #	 the SSL/TLS standard but is needed for some brain-dead browsers. Use
  #	 this when you receive I/O errors because of the standard approach where
  #	 mod_ssl sends the close notify alert.
  #   o ssl-accurate-shutdown:
  #	 This forces an accurate shutdown when the connection is closed, i.e. a
  #	 SSL close notify alert is send and mod_ssl waits for the close notify
  #	 alert of the client. This is 100% SSL/TLS standard compliant, but in
  #	 practice often causes hanging connections with brain-dead browsers. Use
  #	 this only for browsers where you know that their SSL implementation
  #	 works correctly.
  #   Notice: Most problems of broken clients are also related to the HTTP
  #   keep-alive facility, so you usually additionally want to disable
  #   keep-alive for those clients, too. Use variable "nokeepalive" for this.
  #   Similarly, one has to force some clients to use HTTP/1.0 to workaround
  #   their broken HTTP/1.1 implementation. Use variables "downgrade-1.0" and
  #   "force-response-1.0" for this.
  BrowserMatch "MSIE [2-6]" \
  		nokeepalive ssl-unclean-shutdown \
  		downgrade-1.0 force-response-1.0
  # MSIE 7 and newer should be able to use keepalive
  BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown

[/VirtualHost]
[/IfModule]

sorry but the brackets [ ] are standing for these < >

the certificates named in this file dont exist…


#13

I dont know what to do on this file.

i cant disable ssl for port 443 and i cant put in a certificate that exists but doesnt include any of my subdomains (about 9 subdomains…). but the configuration is definetly wrong and i think this is the reason why i get the SSL_POROTOCOL_ERROR in chrome.


#14

The protocol error issue is because Apache HTTPd isn’t serving a proper certificate, as those files don’t exist. If you can’t just comment out all the lines for the VirtualHost block in default-ssl.conf, you could make a self-signed certificate and use the cert and pk for the SSLCertificateFile and SSLCertificateKeyFile lines to get rid of the protocol error issue.


#15

i have commented out the certificates in this file. nothing changes. (i have restarted apache…).

A summary of the problem we want to fix here:

Via letsencrypt i cannot create a certificate for my other virtual hosts than the default-vhost and its alias. This is because letsencrypt tries to visit the vhosts via port 443 and the default-vhost and its alias switch to https without any problems. The other vhosts dont switch to https and then the error comes up. I tryed to put in and tryed to remove the http-to-https-Rewrite-Engine in all vhosts. but nothing changed. even without the Rewrite-Engine every vhost except for one (clouds.acegames.de), which i created some hours ago, automaticly switch to https and i cant disable it. the main problem is that i cant figure out why this Rewrite-Engine is active even if it has been deleted and the Webserver has been restarted several times. More confusing is that the one vhost i just created isnt affected by it.


#16

ive just restarted the Vserver again.
I think i should no longer believe in any logic :grimacing:

All my vhosts: (0=no https rewrite+no error; 1=with https rewrite)

[ 0 ] phpmyadmin.acegames.de
[ 0 ] acegames.de
[ 0 ] www.acegames.de
[ 0 ] clouds.acegames.de
[ 0 ] ts.acegames.de
[ 0 ] en.ts.acegames.de
[ 0 ] en.status.acegames.de
[ 0 ] en.acegames.de
[ 0 ] download.acegames.de
[ 0 ] mailboxes.acegames.de
[ 0 ] wiki.acegames.de
[ 0 ] admin.acegames.de

[ 1 ] cloud.acegames.de
[ 1 ] status.acegames.de
[ 1 ] files.acegames.de

this makes no sense. not even a bit. i’ll restart it again and test them again… :neutral_face:

restarted but nothing more has changed


#17

Do you have rewrites in .htaccess files in those other sub-domains ?


#18

i looked up the .htacces file in the owncloud directory (cloud.acegames.de and clouds.acegames.de and files.acegames.de),
no theres nothing. And even if there was anything, it wouldnt have been activated because i am able to access the site via clouds.acegames.de with normal http.

the other site (status.acegames.de) ist just a regular index.html file. Nothing more up to now.


#19

Sorry, I took your list in the page above to mean that those 3 subdomains were directing to https. I didn’t check them. Having just checked, they aren’t redirecting to https on those, it’s just that you have the server listing http on port 443

Now you aren’t redirecting to https, can you obtain certificates OK for all those domains ?


#20

i will test that in a couple soconds but i wonder why the http listens to port 443 only in these 3 cases. shouldnt that be fixed so that domain+subdomains are all equal in ssl configuration?