Cert creation fails: HAOS with Nginx & LE + Apache2 web server

Help
1

Hi all,

I've been having difficulties getting a cert generated for my self-hosted website. It is running on a VM server with Ubuntu 24.04 and Apache2 web server. I'm trying to generate the certificate via Nginx Proxy manager Add-on on my Home Assistant server. It has been serving me well for two other sites that I'm also self-hosting including the HAOS server itself, so I got two certs generated and they are regularly being successfully renewed using the described setup. This new site shouldn't be any different, but I just can't figure out what setting I might be missing.

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: ok2pad.klobouk.de

I ran this command: not using cmd-prompt directly - I'm using Nginx Proxy Manager Home Assistant add-on web console to generate a certificate via Let's Encrypt service - however the cmd being used in the backend is: certbot certonly --config "/etc/letsencrypt.ini" --work-dir "/tmp/letsencrypt-lib" --logs-dir "/tmp/letsencrypt-log" --cert-name "npm-46" --agree-tos --authenticator webroot --email "@.com" --preferred-challenges "dns,http" --domains "ok2pad.klobouk.de"

It produced this output: Command failed: certbot certonly --config "/etc/letsencrypt.ini" --work-dir "/tmp/letsencrypt-lib" --logs-dir "/tmp/letsencrypt-log" --cert-name "npm-46" --agree-tos --authenticator webroot --email "@.com" --preferred-challenges "dns,http" --domains "ok2pad.klobouk.de"
Saving debug log to /tmp/letsencrypt-log/letsencrypt.log
Some challenges have failed.

My web server is (include version): Apache2 2.4

The operating system my web server runs on is (include version): Ubuntu 24.04

My hosting provider, if applicable, is: Self-hosting

I can login to a root shell on my machine (yes or no, or I don't know): I can login to the HAOS server, but I don't know how to get into the Nginx add-on - it is probably running as a container, I haven't yet tried googling out how to get more data from it... if it is even possible, for now I don't really know if I can even get to that /tmp/letsencrypt-log folder anyhow...

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

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): Not sure how to get this info from the HAOS server

I have both ports 80 and 443 opened on my router towards the HAOS instance where NPM is running. I also have these ports allowed on the webserver - the site is actually accessbile via HTTP at the moment.

I've tried using letsdebug, but I'm getting strange outputs there - for instance msg saying:

ok2pad.klobouk.de has an A (IPv4) record (91.139.111.191) but a request to this address over port 80 did not succeed. Your web server must have at least one working IPv4 or IPv6 address.

A timeout was experienced while communicating with ok2pad.klobouk.de/91.139.111.191: Get "http://ok2pad.klobouk.de/.well-known/acme-challenge/letsdebug-test": context deadline exceeded

...which doesn't make any sense to me since the web itself is perfectly fine and can be accessed using the very same URL as mentioned above.

Thanks in advance to anyone willing to help me look into this.

2

Only from a couple places in the world.

You may find this description of how Let's Encrypt checks from multiple places around the world helpful:

3 Likes
3

Thank you for your answer, Peter. It's a pretty interesting behavior with the limited accessibility and I was not aware of it till now.

What is strange about it is that my other two certificates were created without any problems, one of them relatively recently within last month or so. These other domains are subdomains of the same second level domain klobouk.de and their hosts sit behind the same public IP address, so is this multi-perspective validation something that was only recently introduced?

Thanks again...

4

Also as I'm randomly trying the multi location accessibility check - the results do seem to be quite random... one time Brazil responds okay, second time it times out and other location that previously timed out succeeds. Not sure what to take away from that... :slight_smile:

5

Maybe it's not actually location-based but your connection is just overloaded or not working right somehow.

2 Likes
6

Note your other two domains cannot be seen consistently by Let's Debug right now. Should they be available using HTTP with port 80?

As you can see, the connectivity results are inconsistent. One test just failing from the Let's Debug test server and the other failing that and the Let's Encrypt Staging system test.

Likely something within your local network routing to be seen from such varied locations.

4 Likes
7

Thanks Mike.

Both of these domains should only be accessible via HTTPS, not via port 80.

8

And as for my local network, I'm on a relatively low-bandwidth VDSL broadband connection - 50/10Mbit, but I've been able to access my HAOS instance from remote locations, even from abroad without any problems during last 3 or so years reliably. I don't think it's local routing...

9

Then it's even more confusing as an HTTP request (port 80) from the Let's Encrypt staging server reached one of them.

Verbose output from Let's Debug. Note the HTTPS in the URL and a 404. The only way the LE Staging system would try HTTPS (seen in the error msg) is if HTTP worked and redirected it there.

acme: error code 403 "urn:ietf:params:acme:error:unauthorized": 91.139.111.191: Invalid response from https://haos.klobouk.de/.well-known/acme-challenge/sjdkQQKaeIpk8xxa5ERimClcg6reGa9wfWHgkndErkI: 404

How did you get their certs originally? An HTTP Challenge requires access by HTTP on port 80.

3 Likes
10

Very inconsistent results from a timing perspective; real 0m0.641s vs real 0m12.011s.

$ time curl -Ii https://haos.klobouk.de/
HTTP/2 405
server: nginx
date: Mon, 12 May 2025 22:23:26 GMT
content-type: text/plain; charset=utf-8
content-length: 23
allow: GET
referrer-policy: no-referrer
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN


real    0m0.641s
user    0m0.132s
sys     0m0.016s

$ time curl -Ii https://haos.klobouk.de/
HTTP/2 405
server: nginx
date: Mon, 12 May 2025 22:23:39 GMT
content-type: text/plain; charset=utf-8
content-length: 23
allow: GET
referrer-policy: no-referrer
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN


real    0m12.011s
user    0m0.126s
sys     0m0.018s
2 Likes
11

And the firewall is filtering Ports 80 & 443 from nmap point of view.

$ nmap -Pn -p80,443 haos.klobouk.de
Starting Nmap 7.94SVN ( https://nmap.org ) at 2025-05-12 22:25 UTC
Nmap scan report for haos.klobouk.de (91.139.111.191)
Host is up.
rDNS record for 91.139.111.191: 91-139-111-191.customers.tmcz.cz

PORT    STATE    SERVICE
80/tcp  filtered http
443/tcp filtered https

Nmap done: 1 IP address (1 host up) scanned in 3.22 seconds
2 Likes
12

I'll try and describe the setup a bit more...

On my router I've got port forwarding set up for 80/443 towards the LAN IP of my HAOS server which is hosting the Nginx Proxy Manager. HAOS web for instance is available via its standard port 8123 locally on LAN.

In NPM I defined a proxy host for http://<haos_lan_ip>:8123 and set the SSL setting to generate new cert with Let'sEncrypt and it just worked like that.

For Plex the proxy host setup is a little different in that it uses https (without cert) out of the box on its default port 32400, so the host config looks like this: https://<plex_lan_ip>:32400 and I think the cert creation failed on the first attempt, but succeeded on the second try.

My dad's ok2pad website was set up to run on port 80, but since I couldn't get the cert created, I tried changing its port to 8080 which didn't help, but that's what it runs on right now and in NPM it is set as http://ok2pad_lan_ip:8080.

On Plex and HAOS I have the Force SSL setting enabled.

13

Supplemental information:

This works:

openssl s_client -showcerts -servername haos.klobouk.de -connect haos.klobouk.de:443 
$ openssl s_client -showcerts -servername haos.klobouk.de -connect haos.klobouk.de:443 < /dev/null
CONNECTED(00000003)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = E6
verify return:1
depth=0 CN = haos.klobouk.de
verify return:1
---
Certificate chain
 0 s:CN = haos.klobouk.de
   i:C = US, O = Let's Encrypt, CN = E6
   a:PKEY: id-ecPublicKey, 384 (bit); sigalg: ecdsa-with-SHA384
   v:NotBefore: Mar 20 20:15:07 2025 GMT; NotAfter: Jun 18 20:15:06 2025 GMT
-----BEGIN CERTIFICATE-----
MIIDyzCCA1GgAwIBAgISBo9tlDxverC55NNfx4JP41iIMAoGCCqGSM49BAMDMDIx
CzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQDEwJF
NjAeFw0yNTAzMjAyMDE1MDdaFw0yNTA2MTgyMDE1MDZaMBoxGDAWBgNVBAMTD2hh
b3Mua2xvYm91ay5kZTB2MBAGByqGSM49AgEGBSuBBAAiA2IABEknwI2Gv1KpitIq
PEZOqaQHC564sJDQ2KnZjcM6hs8skG39Eowx3n//tFaFyBVM5kO9+Qla6DCwPly8
GSVSNIWC3Q9LMgxJvs2HnZjLMMmQKEyjp8WcCLu/UpTWB4ayKaOCAkAwggI8MA4G
A1UdDwEB/wQEAwIHgDAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwDAYD
VR0TAQH/BAIwADAdBgNVHQ4EFgQUGB4s+FqPfioQS7kXWkGKbnEDnE8wHwYDVR0j
BBgwFoAUkydGmAOpUWiOmNbEQkjbI79YlNIwVQYIKwYBBQUHAQEESTBHMCEGCCsG
AQUFBzABhhVodHRwOi8vZTYuby5sZW5jci5vcmcwIgYIKwYBBQUHMAKGFmh0dHA6
Ly9lNi5pLmxlbmNyLm9yZy8wGgYDVR0RBBMwEYIPaGFvcy5rbG9ib3VrLmRlMBMG
A1UdIAQMMAowCAYGZ4EMAQIBMCwGA1UdHwQlMCMwIaAfoB2GG2h0dHA6Ly9lNi5j
LmxlbmNyLm9yZy85LmNybDCCAQUGCisGAQQB1nkCBAIEgfYEgfMA8QB2AMz7D2qF
cQll/pWbU87psnwi6YVcDZeNtql+VMD+TA2wAAABlbVnjgAAAAQDAEcwRQIgHS0R
Mqa8ua01hn+RBkVwHyb3tqbrV9REdspVKWyrbYsCIQC0xljZZxKAGNEa4UN+5VR7
qv/WnwEq7nxMZp0xvUq6UgB3AKLjCuRF772tm3447Udnd1PXgluElNcrXhssxLlQ
pEfnAAABlbVnjgoAAAQDAEgwRgIhAJYtig3klGwFiXHbkVyx2HYJM03pu7H0xSc3
NmbqZxYbAiEAh8Unbm/bvVeUgyj8tgRokvY7qxyog5aTYoLwNBMNtogwCgYIKoZI
zj0EAwMDaAAwZQIxAPPvplaKKyzv6xdKju/k6UN3/M/ubJoX8FX8vtz1vBRrdKEs
oJ7A7pSADr5zRvGYvQIwKL6zEsj4H4wd9XojbCwRLqbdKjP5a3dqxwZzbmruVdEo
HwSINYMqP6A1Cso0Ju5v
-----END CERTIFICATE-----
 1 s:C = US, O = Let's Encrypt, CN = E6
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
   a:PKEY: id-ecPublicKey, 384 (bit); sigalg: RSA-SHA256
   v:NotBefore: Mar 13 00:00:00 2024 GMT; NotAfter: Mar 12 23:59:59 2027 GMT
-----BEGIN CERTIFICATE-----
MIIEVzCCAj+gAwIBAgIRALBXPpFzlydw27SHyzpFKzgwDQYJKoZIhvcNAQELBQAw
TzELMAkGA1UEBhMCVVMxKTAnBgNVBAoTIEludGVybmV0IFNlY3VyaXR5IFJlc2Vh
cmNoIEdyb3VwMRUwEwYDVQQDEwxJU1JHIFJvb3QgWDEwHhcNMjQwMzEzMDAwMDAw
WhcNMjcwMzEyMjM1OTU5WjAyMQswCQYDVQQGEwJVUzEWMBQGA1UEChMNTGV0J3Mg
RW5jcnlwdDELMAkGA1UEAxMCRTYwdjAQBgcqhkjOPQIBBgUrgQQAIgNiAATZ8Z5G
h/ghcWCoJuuj+rnq2h25EqfUJtlRFLFhfHWWvyILOR/VvtEKRqotPEoJhC6+QJVV
6RlAN2Z17TJOdwRJ+HB7wxjnzvdxEP6sdNgA1O1tHHMWMxCcOrLqbGL0vbijgfgw
gfUwDgYDVR0PAQH/BAQDAgGGMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcD
ATASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQWBBSTJ0aYA6lRaI6Y1sRCSNsj
v1iU0jAfBgNVHSMEGDAWgBR5tFnme7bl5AFzgAiIyBpY9umbbjAyBggrBgEFBQcB
AQQmMCQwIgYIKwYBBQUHMAKGFmh0dHA6Ly94MS5pLmxlbmNyLm9yZy8wEwYDVR0g
BAwwCjAIBgZngQwBAgEwJwYDVR0fBCAwHjAcoBqgGIYWaHR0cDovL3gxLmMubGVu
Y3Iub3JnLzANBgkqhkiG9w0BAQsFAAOCAgEAfYt7SiA1sgWGCIpunk46r4AExIRc
MxkKgUhNlrrv1B21hOaXN/5miE+LOTbrcmU/M9yvC6MVY730GNFoL8IhJ8j8vrOL
pMY22OP6baS1k9YMrtDTlwJHoGby04ThTUeBDksS9RiuHvicZqBedQdIF65pZuhp
eDcGBcLiYasQr/EO5gxxtLyTmgsHSOVSBcFOn9lgv7LECPq9i7mfH3mpxgrRKSxH
pOoZ0KXMcB+hHuvlklHntvcI0mMMQ0mhYj6qtMFStkF1RpCG3IPdIwpVCQqu8GV7
s8ubknRzs+3C/Bm19RFOoiPpDkwvyNfvmQ14XkyqqKK5oZ8zhD32kFRQkxa8uZSu
h4aTImFxknu39waBxIRXE4jKxlAmQc4QjFZoq1KmQqQg0J/1JF8RlFvJas1VcjLv
YlvUB2t6npO6oQjB3l+PNf0DpQH7iUx3Wz5AjQCi6L25FjyE06q6BZ/QlmtYdl/8
ZYao4SRqPEs/6cAiF+Qf5zg2UkaWtDphl1LKMuTNLotvsX99HP69V2faNyegodQ0
LyTApr/vT01YPE46vNsDLgK+4cL6TrzC/a4WcmF5SRJ938zrv/duJHLXQIku5v0+
EwOy59Hdm0PT/Er/84dDV0CSjdR/2XuZM3kpysSKLgD1cKiDA+IRguODCxfO9cyY
Ig46v9mFmBvyH04=
-----END CERTIFICATE-----
---
Server certificate
subject=CN = haos.klobouk.de
issuer=C = US, O = Let's Encrypt, CN = E6
---
No client certificate CA names sent
Peer signing digest: SHA384
Peer signature type: ECDSA
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 2502 bytes and written 397 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 384 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
DONE

This works:

openssl s_client -showcerts -servername plex.klobouk.de -connect plex.klobouk.de:443 
$ openssl s_client -showcerts -servername plex.klobouk.de -connect plex.klobouk.de:443 < /dev/null
CONNECTED(00000003)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = E5
verify return:1
depth=0 CN = plex.klobouk.de
verify return:1
---
Certificate chain
 0 s:CN = plex.klobouk.de
   i:C = US, O = Let's Encrypt, CN = E5
   a:PKEY: id-ecPublicKey, 384 (bit); sigalg: ecdsa-with-SHA384
   v:NotBefore: Apr 24 03:19:53 2025 GMT; NotAfter: Jul 23 03:19:52 2025 GMT
-----BEGIN CERTIFICATE-----
MIIDzjCCA1OgAwIBAgISBqYOZ8NAdVyUj3al88J2WrR3MAoGCCqGSM49BAMDMDIx
CzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQDEwJF
NTAeFw0yNTA0MjQwMzE5NTNaFw0yNTA3MjMwMzE5NTJaMBoxGDAWBgNVBAMTD3Bs
ZXgua2xvYm91ay5kZTB2MBAGByqGSM49AgEGBSuBBAAiA2IABOvWN9WO2rJhVVUK
789UlAnggqbJ+TG16yvifyIQVoxV5BUM8Wb9jzKbRxiQ4K2byuyrjuUNh0Vyeng4
nBg4SqW4TQeoWGNmGa3rfr5u4sHzM2tuApovdeuUI4/XfryflqOCAkIwggI+MA4G
A1UdDwEB/wQEAwIHgDAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwDAYD
VR0TAQH/BAIwADAdBgNVHQ4EFgQU+odDhTmNhS4XXSFurzhjwzgR4NUwHwYDVR0j
BBgwFoAUnytfzzwhT50Et+0rLMTGcIvS1w0wVQYIKwYBBQUHAQEESTBHMCEGCCsG
AQUFBzABhhVodHRwOi8vZTUuby5sZW5jci5vcmcwIgYIKwYBBQUHMAKGFmh0dHA6
Ly9lNS5pLmxlbmNyLm9yZy8wGgYDVR0RBBMwEYIPcGxleC5rbG9ib3VrLmRlMBMG
A1UdIAQMMAowCAYGZ4EMAQIBMC4GA1UdHwQnMCUwI6AhoB+GHWh0dHA6Ly9lNS5j
LmxlbmNyLm9yZy8xMjAuY3JsMIIBBQYKKwYBBAHWeQIEAgSB9gSB8wDxAHYAzPsP
aoVxCWX+lZtTzumyfCLphVwNl422qX5UwP5MDbAAAAGWZgSqpAAABAMARzBFAiEA
5H8HKLixqgIBRbymQGVV0mMjo4bQLY4vT6/ztM8iwi4CIB0z82tsq+kmZPn5lS5O
NBEqw9YWPUWL6/XtW+HDm10mAHcAEvFONL1TckyEBhnDjz96E/jntWKHiJxtMAWE
6+WGJjoAAAGWZgSqmgAABAMASDBGAiEAwidh/TCPthBaAZosseUaSqmPT1NHZo69
tTcGYR7PZJQCIQDkEtz3hyQH7vBHXpJZ7akmBI3EQkWfG5jYvSzAnw9i6DAKBggq
hkjOPQQDAwNpADBmAjEAhLlSRNY2/wneq0XlgdosI01QKr7Z6GEuk7c07KqdTi0S
ayqYFrAd11J7Vq6ACA66AjEApIVgDGF0OivTT8NL8qzpIjIxYYrvECeKFbarsFOp
z5LIgjbNqeeDF0XQAhi4p3NJ
-----END CERTIFICATE-----
 1 s:C = US, O = Let's Encrypt, CN = E5
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
   a:PKEY: id-ecPublicKey, 384 (bit); sigalg: RSA-SHA256
   v:NotBefore: Mar 13 00:00:00 2024 GMT; NotAfter: Mar 12 23:59:59 2027 GMT
-----BEGIN CERTIFICATE-----
MIIEVzCCAj+gAwIBAgIRAIOPbGPOsTmMYgZigxXJ/d4wDQYJKoZIhvcNAQELBQAw
TzELMAkGA1UEBhMCVVMxKTAnBgNVBAoTIEludGVybmV0IFNlY3VyaXR5IFJlc2Vh
cmNoIEdyb3VwMRUwEwYDVQQDEwxJU1JHIFJvb3QgWDEwHhcNMjQwMzEzMDAwMDAw
WhcNMjcwMzEyMjM1OTU5WjAyMQswCQYDVQQGEwJVUzEWMBQGA1UEChMNTGV0J3Mg
RW5jcnlwdDELMAkGA1UEAxMCRTUwdjAQBgcqhkjOPQIBBgUrgQQAIgNiAAQNCzqK
a2GOtu/cX1jnxkJFVKtj9mZhSAouWXW0gQI3ULc/FnncmOyhKJdyIBwsz9V8UiBO
VHhbhBRrwJCuhezAUUE8Wod/Bk3U/mDR+mwt4X2VEIiiCFQPmRpM5uoKrNijgfgw
gfUwDgYDVR0PAQH/BAQDAgGGMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcD
ATASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQWBBSfK1/PPCFPnQS37SssxMZw
i9LXDTAfBgNVHSMEGDAWgBR5tFnme7bl5AFzgAiIyBpY9umbbjAyBggrBgEFBQcB
AQQmMCQwIgYIKwYBBQUHMAKGFmh0dHA6Ly94MS5pLmxlbmNyLm9yZy8wEwYDVR0g
BAwwCjAIBgZngQwBAgEwJwYDVR0fBCAwHjAcoBqgGIYWaHR0cDovL3gxLmMubGVu
Y3Iub3JnLzANBgkqhkiG9w0BAQsFAAOCAgEAH3KdNEVCQdqk0LKyuNImTKdRJY1C
2uw2SJajuhqkyGPY8C+zzsufZ+mgnhnq1A2KVQOSykOEnUbx1cy637rBAihx97r+
bcwbZM6sTDIaEriR/PLk6LKs9Be0uoVxgOKDcpG9svD33J+G9Lcfv1K9luDmSTgG
6XNFIN5vfI5gs/lMPyojEMdIzK9blcl2/1vKxO8WGCcjvsQ1nJ/Pwt8LQZBfOFyV
XP8ubAp/au3dc4EKWG9MO5zcx1qT9+NXRGdVWxGvmBFRAajciMfXME1ZuGmk3/GO
koAM7ZkjZmleyokP1LGzmfJcUd9s7eeu1/9/eg5XlXd/55GtYjAM+C4DG5i7eaNq
cm2F+yxYIPt6cbbtYVNJCGfHWqHEQ4FYStUyFnv8sjyqU8ypgZaNJ9aVcWSICLOI
E1/Qv/7oKsnZCWJ926wU6RqG1OYPGOi1zuABhLw61cuPVDT28nQS/e6z95cJXq0e
K1BcaJ6fJZsmbjRgD5p3mvEf5vdQM7MCEvU0tHbsx2I5mHHJoABHb8KVBgWp/lcX
GWiWaeOyB7RP+OfDtvi2OsapxXiV7vNVs7fMlrRjY1joKaqmmycnBvAq14AEbtyL
sVfOS66B8apkeFX2NY4XPEYV4ZSCe8VHPrdrERk2wILG3T/EGmSIkCYVUMSnjmJd
VQD9F6Na/+zmXCc=
-----END CERTIFICATE-----
---
Server certificate
subject=CN = plex.klobouk.de
issuer=C = US, O = Let's Encrypt, CN = E5
---
No client certificate CA names sent
Peer signing digest: SHA384
Peer signature type: ECDSA
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 2504 bytes and written 397 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 384 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
DONE

This FAILS:

openssl s_client -showcerts -servername ok2pad.klobouk.de -connect ok2pad.klobouk.de:443 
$ openssl s_client -showcerts -servername ok2pad.klobouk.de -connect ok2pad.klobouk.de:443 < /dev/null
4007D806A1740000:error:8000006E:system library:BIO_connect:Connection timed out:../crypto/bio/bio_sock2.c:114:calling connect()
4007D806A1740000:error:10000067:BIO routines:BIO_connect:connect error:../crypto/bio/bio_sock2.c:116:

Edit

Yet for haos.klobouk.de here Permanent link to this check report and the following runs here Check website performance and response : Check host - online website monitoring and Check website performance and response : Check host - online website monitoring are not consistently getting the same results. Most locations most of the time are getting "Connection timed out".

2 Likes
14

Bruce, thanks a lot for these pointers - it led me to look into my router's firewall settings and ...well at first I simply decided to turn it off and try obtaining the cert again and it worked like a charm.

Then I tried enabling it again with various settings on and off, turned out that with enabled DDOS protection all these HTTP checks you, Mike and Peter have mentioned would time out, once I disabled DDOS protection, I started getting consistent responses.

I don't really have any known FW rules set up there, just something ASUS refers to as Basic IPv4 rules - haven't googled what ports/protocols it includes, but it seems it was the DDOS protection menchanisms that would not play well with the Let's Encript website / dns checks...

Thanks you all for all the inputs and suggestions... much appreciated!!

5 Likes
15

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