root@MiniDLNA:/etc/apache2# certbot --apache
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator apache, Installer apache
No names were found in your configuration files. Please enter in your domain
name(s) (comma and/or space separated) (Enter 'c' to cancel): yuy3v0n.de
Obtaining a new certificate
Performing the following challenges:
tls-sni-01 challenge for yuy3v0n.de
Waiting for verification...
Cleaning up challenges
Failed authorization procedure. yuy3v0n.de (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Connection refused
IMPORTANT NOTES:
- The following errors were reported by the server:
Domain: yuy3v0n.de
Type: connection
Detail: Connection refused
To fix these errors, please make sure that your domain name was
entered correctly and the DNS A/AAAA 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.
My web server is (include version):
root@MiniDLNA:/etc/apache2# dpkg -l |grep apache
ii apache2 2.4.18-2ubuntu3.5 amd64 Apache HTTP Server
ii apache2-bin 2.4.18-2ubuntu3.5 amd64 Apache HTTP Server (modules and other binary files)
ii apache2-data 2.4.18-2ubuntu3.5 all Apache HTTP Server (common files)
ii apache2-utils 2.4.18-2ubuntu3.5 amd64 Apache HTTP Server (utility programs for web servers)
ii python-certbot-apache 0.19.0-1+ubuntu16.04.1+certbot+1 all Apache plugin for Certbot
The operating system my web server runs on is (include version):
Linux version 4.4.0-103-generic (buildd@lcy01-amd64-001) (gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.5) ) #126-Ubuntu SMP Mon Dec 4 16:23:28 UTC 2017
My hosting provider, if applicable, is: INWX (www.inwx.de)
I can login to a root shell on my machine: yes - only using shell, but I have installed a GUI aswell.
I’m using a control panel to manage my site : if the question means that i changed anything on my apache config. I did, like enabling SSL via a2ensite or a2enmod ssl / headers
Here some nmap scans
$ /etc/apache2 # nmap 77.23.113.127 -sV
Starting Nmap 6.47 ( http://nmap.org ) at 2017-12-12 15:27 CET
Nmap scan report for ip4d17717f.dynamic.kabel-deutschland.de (77.23.113.127)
Host is up (0.052s latency).
Not shown: 998 filtered ports
PORT STATE SERVICE VERSION
80/tcp open http Apache httpd 2.4.18 ((Ubuntu))
443/tcp open ssl/http Apache httpd 2.4.18 ((Ubuntu))
Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 38.01 seconds
Despite the nmap scan showing 443 as state "open" I receive the same error as was returned to Certbot from the validation server when I try to connect to your website on port 443:
root@MiniDLNA:/etc/apache2# cat ports.conf
# If you just change the port or add more ports here, you will likely also
# have to change the VirtualHost statement in
# /etc/apache2/sites-enabled/000-default.conf
Listen 80
#<IfModule ssl_module>
Listen 443
#</IfModule>
#<IfModule mod_gnutls.c>
# Listen 443
#</IfModule>
# vim: syntax=apache ts=4 sw=4 sts=4 sr noet
I even commented the If-clause out…
here the heads of the default.conf and the default-ssl.conf
root@MiniDLNA:/etc/apache2# head sites-enabled/*
==> sites-enabled/000-default.conf <==
<VirtualHost *:80>
# 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 www.example.com
==> sites-enabled/default-ssl.conf <==
<IfModule mod_ssl.c>
<VirtualHost _default_:443>
ServerAdmin webmaster@localhost
DocumentRoot /var/www/html
# Enable HSTS - stick to https after first successful https connect
# http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
Header always set Strict-Transport-Security: "max-age=15768000"
Hi again @YuY3v0n - I noticed this is not the IP address that yuy3v0n.de resolves to for both myself and the validation authority. We're resolving 185.181.104.74
That probably explains your problem. Sure enough while 185.181.104.74 isn't listening on :443, 77.23.113.127 is.
Can you check your DNS? I think at least one of your authoritative nameservers is returning the wrong IP.
The TTL might mean end users will reach the wrong IP for a little while because of cached responses but you should be able to issue a certificate right now. The Let's Encrypt validation server directly queries your authoritative nameservers and doesn't keep a long cache. Might be worth trying
You were bloody right.
Let’s Encrypt worked properly. We use LE on our servers in our company aswell, but I have never set it Up by my own. Really impressing.
Do you have any preferred options?
Aha! I'm afraid I work on the server-side of Let's Encrypt and don't have any good tips for Certbot. I recommend you start a new thread in the help topic with the subject "Certbot: Recommended configuration options/best practices" or something similar. There are lots of Certbot users in the forum who would likely reply to that thread.
thank you mate
