Sslh Multiplexer On Linux Systems Causing Certbot TLS-SNI Challenge to Fail

Could you help me to renew my certificat :frowning:)

I have all time this problem !

My log;

root@cloud:~# certbot --apache --verbose
Root logging level set at 10
Saving debug log to /var/log/letsencrypt/letsencrypt.log
certbot version: 0.11.1
Arguments: [’–apache’, ‘–verbose’]
Discovered plugins: PluginsRegistry(PluginEntryPoint#apache,PluginEntryPoint#webroot,PluginEntryPoint#null,PluginEntryPoint#manual,PluginEntryPoint#standalone)
Requested authenticator apache and installer apache
Single candidate plugin: * apache
Description: Apache Web Server plugin - Beta
Interfaces: IAuthenticator, IInstaller, IPlugin
Entry point: apache = certbot_apache.configurator:ApacheConfigurator
Initialized: <certbot_apache.configurator.ApacheConfigurator object at 0x7f254969ad50>
Prep: True
Selected authenticator <certbot_apache.configurator.ApacheConfigurator object at 0x7f254969ad50> and installer <certbot_apache.configurator.ApacheConfigurator object at 0x7f254969ad50>

Which names would you like to activate HTTPS for?

1: cloud.moulard.org

Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter ‘c’ to cancel):
Picked account: <Account(936c8dfdfeb2689cdc12704f734a41aa)>
Sending GET request to https://acme-v01.api.letsencrypt.org/directory.
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
"GET /directory HTTP/1.1" 200 352
Received response:
HTTP 200
Content-Length: 352
Strict-Transport-Security: max-age=604800
Boulder-Request-Id: UvbebtTwz19PNeswhXnTunobNoAWrD2BOTnT7VDif9Q
Expires: Wed, 03 May 2017 14:28:53 GMT
Server: nginx
Connection: keep-alive
Pragma: no-cache
Cache-Control: max-age=0, no-cache, no-store
Date: Wed, 03 May 2017 14:28:53 GMT
X-Frame-Options: DENY
Content-Type: application/json
Replay-Nonce: Bul_7YFRa-7nDih_37FwzR0-c8WRJXHZ1DjzzeA68Bg

{
“key-change”: “https://acme-v01.api.letsencrypt.org/acme/key-change”,
“new-authz”: “https://acme-v01.api.letsencrypt.org/acme/new-authz”,
“new-cert”: “https://acme-v01.api.letsencrypt.org/acme/new-cert”,
“new-reg”: “https://acme-v01.api.letsencrypt.org/acme/new-reg”,
“revoke-cert”: “https://acme-v01.api.letsencrypt.org/acme/revoke-cert
}
parse (top of loop): [30 days][]
CRE_UNITS matched
parse (bottom) [][30 days][][]
weekday False, dateStd False, dateStr False, time False, timeStr False, meridian False
dayStr False, modifier False, modifier2 False, units True, qunits False
_evalString(30 days, time.struct_time(tm_year=2017, tm_mon=5, tm_mday=3, tm_hour=14, tm_min=28, tm_sec=53, tm_wday=2, tm_yday=123, tm_isdst=0))
_buildTime: [30 ][][days]
units days --> realunit days
return
Should renew, less than 30 days before certificate expiry 2017-05-01 12:28:00 UTC.
Cert is due for renewal, auto-renewing…
Renewing an existing certificate
Requesting fresh nonce
Sending HEAD request to https://acme-v01.api.letsencrypt.org/acme/new-authz.
“HEAD /acme/new-authz HTTP/1.1” 405 0
Received response:
HTTP 405
Content-Length: 91
Allow: POST
Boulder-Request-Id: XhFO4hnZXrNVctdLAh5t8lYKMui_JIuuA_GmQNLpWtY
Expires: Wed, 03 May 2017 14:28:53 GMT
Server: nginx
Connection: keep-alive
Pragma: no-cache
Cache-Control: max-age=0, no-cache, no-store
Date: Wed, 03 May 2017 14:28:53 GMT
Content-Type: application/problem+json
Replay-Nonce: w3VO_DzJKAANA20lHXQS2rYJmj98eUrBjLo68ZBjllk

Storing nonce: w3VO_DzJKAANA20lHXQS2rYJmj98eUrBjLo68ZBjllk
JWS payload:
{
“identifier”: {
“type”: “dns”,
“value”: “cloud.moulard.org
},
“resource”: “new-authz”
}
Sending POST request to https://acme-v01.api.letsencrypt.org/acme/new-authz:
{
“header”: {
“alg”: “RS256”,
“jwk”: {
“e”: “AQAB”,
“kty”: “RSA”,
“n”: “uNFYM7q0pxH4OnwMC_2ZkDWkzRgDFeJUCFEm-p3yQQjuCOH5A8vlXaHx3HNrkWqq9NDsfGgMWaFXlamOauUA6Nlp3lk_NEmT_dA7ng4XNMDFtrPjhw4D3HigUOkwkyWwpbMl5ZFqoeN8cUr7Zg2mFSnkbyerO0wnccqWz_rgbJ1BbN7rK-qZaYLnIbNi3rr9YbjzAfrfeIJTLxcDZQsz-uRHL-yD5Q8SZQuw0MaYjw8GtM3UiFBUcJHft7Dy_pOKzXdwzo48E4n3j2wl4nAx9Z2zNa2cKupub0HTsz5Ix11tKCEz_hmdjW5QPaC9sDUaqaGvEk71qhwvphfqUL6rVQ”
}
},
“protected”: “eyJub25jZSI6ICJ3M1ZPX0R6SktBQU5BMjBsSFhRUzJyWUptajk4ZVVyQmpMbzY4WkJqbGxrIn0”,
“payload”: “ewogICJpZGVudGlmaWVyIjogewogICAgInR5cGUiOiAiZG5zIiwgCiAgICAidmFsdWUiOiAiY2xvdWQubW91bGFyZC5vcmciCiAgfSwgCiAgInJlc291cmNlIjogIm5ldy1hdXRoeiIKfQ”,
“signature”: “R8XhaWinaZaiYfF-uDV-MHDmQYr_rihdpYRr9kE3Vp3x-kB46Fajxc9q8MbBqiwgJSJRZRE1GFSPQOjrF8Cmmmel9ZIsPmy4CGWVIaOvUhdsJ0TqT1kDLczLl2pFbte8y88eqIJ4fg0Qt0h9ZX0JKB4k4eVjjS64DDdf8HDFQ2s0k7VYVLlmaFnd1062PUO3Q2tgn5eAreysEipCrpQsm5a_C6eGsd5nMP9lm8cuUCpPdmXRr3jnLcNFGME_ErAdNKEGihNGZGqoSbVCVILQWw11VgNG6MZYJy55nfIDZtola1ypYL3H-BrmISb5NaX8XeIYaTHQllFjCYsL8zHkig”
}
“POST /acme/new-authz HTTP/1.1” 201 1005
Received response:
HTTP 201
Content-Length: 1005
Strict-Transport-Security: max-age=604800
Boulder-Request-Id: UmQei6f0Zv3pGL55WE3ZlPmcY18Rp4TP68jYuQljjOM
Boulder-Requester: 6416818
Expires: Wed, 03 May 2017 14:28:54 GMT
Server: nginx
Connection: keep-alive
Link: https://acme-v01.api.letsencrypt.org/acme/new-cert;rel="next"
Location: https://acme-v01.api.letsencrypt.org/acme/authz/DHB3z49MRy-sOHZtgflZKdaZkDTqiYQdpUCwR5yHUjk
Pragma: no-cache
Cache-Control: max-age=0, no-cache, no-store
Date: Wed, 03 May 2017 14:28:54 GMT
X-Frame-Options: DENY
Content-Type: application/json
Replay-Nonce: 7P4Ysqp3K3ddqbce28mxDrAvO3b5Z0_EPK9i0exlkV8

{
“identifier”: {
“type”: “dns”,
“value”: “cloud.moulard.org
},
“status”: “pending”,
“expires”: “2017-05-10T14:28:54.074837739Z”,
“challenges”: [
{
“type”: “tls-sni-01”,
“status”: “pending”,
“uri”: “https://acme-v01.api.letsencrypt.org/acme/challenge/DHB3z49MRy-sOHZtgflZKdaZkDTqiYQdpUCwR5yHUjk/1119902566”,
“token”: “482mupyLCQvz-2Vuz6jtcOBZqlXuU88IsWXsUGExAL4”
},
{
“type”: “http-01”,
“status”: “pending”,
“uri”: “https://acme-v01.api.letsencrypt.org/acme/challenge/DHB3z49MRy-sOHZtgflZKdaZkDTqiYQdpUCwR5yHUjk/1119902569”,
“token”: “5UjCMjdiveMZqvSKWMvKyR8xOxKvqr3FgzR-o5tFcG0”
},
{
“type”: “dns-01”,
“status”: “pending”,
“uri”: “https://acme-v01.api.letsencrypt.org/acme/challenge/DHB3z49MRy-sOHZtgflZKdaZkDTqiYQdpUCwR5yHUjk/1119902570”,
“token”: “oTJh018Mi8kNocmrPhHBzTAWxW_85UzWdsdPFPQ3ncM”
}
],
“combinations”: [
[
2
],
[
0
],
[
1
]
]
}
Storing nonce: 7P4Ysqp3K3ddqbce28mxDrAvO3b5Z0_EPK9i0exlkV8
Performing the following challenges:
tls-sni-01 challenge for cloud.moulard.org
Adding Include /etc/apache2/le_tls_sni_01_cert_challenge.conf to /files/etc/apache2/apache2.conf
writing a config file with text:

<VirtualHost *:443>
ServerName 11629ff4f98208a8bbaa51c7eddc8247.a543a0da26b87bbc7f1a4f0e4a7f6c83.acme.invalid
UseCanonicalName on
SSLStrictSNIVHostCheck on

LimitRequestBody 1048576

Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateFile /var/lib/letsencrypt/482mupyLCQvz-2Vuz6jtcOBZqlXuU88IsWXsUGExAL4.crt
SSLCertificateKeyFile /var/lib/letsencrypt/482mupyLCQvz-2Vuz6jtcOBZqlXuU88IsWXsUGExAL4.pem

DocumentRoot /var/lib/letsencrypt/tls_sni_01_page/

Creating backup of /etc/apache2/ports.conf
Creating backup of /etc/apache2/apache2.conf
Waiting for verification…
JWS payload:
{
“keyAuthorization”: “482mupyLCQvz-2Vuz6jtcOBZqlXuU88IsWXsUGExAL4.M-D0FPuVtPZedbURF6AQ7cRQg3BF3WH9b7pnK-k5IbA”,
“type”: “tls-sni-01”,
“resource”: “challenge”
}
Sending POST request to https://acme-v01.api.letsencrypt.org/acme/challenge/DHB3z49MRy-sOHZtgflZKdaZkDTqiYQdpUCwR5yHUjk/1119902566:
{
“header”: {
“alg”: “RS256”,
“jwk”: {
“e”: “AQAB”,
“kty”: “RSA”,
“n”: “uNFYM7q0pxH4OnwMC_2ZkDWkzRgDFeJUCFEm-p3yQQjuCOH5A8vlXaHx3HNrkWqq9NDsfGgMWaFXlamOauUA6Nlp3lk_NEmT_dA7ng4XNMDFtrPjhw4D3HigUOkwkyWwpbMl5ZFqoeN8cUr7Zg2mFSnkbyerO0wnccqWz_rgbJ1BbN7rK-qZaYLnIbNi3rr9YbjzAfrfeIJTLxcDZQsz-uRHL-yD5Q8SZQuw0MaYjw8GtM3UiFBUcJHft7Dy_pOKzXdwzo48E4n3j2wl4nAx9Z2zNa2cKupub0HTsz5Ix11tKCEz_hmdjW5QPaC9sDUaqaGvEk71qhwvphfqUL6rVQ”
}
},
“protected”: “eyJub25jZSI6ICI3UDRZc3FwM0szZGRxYmNlMjhteERyQXZPM2I1WjBfRVBLOWkwZXhsa1Y4In0”,
“payload”: “ewogICJrZXlBdXRob3JpemF0aW9uIjogIjQ4Mm11cHlMQ1F2ei0yVnV6Nmp0Y09CWnFsWHVVODhJc1dYc1VHRXhBTDQuTS1EMEZQdVZ0UFplZGJVUkY2QVE3Y1JRZzNCRjNXSDliN3BuSy1rNUliQSIsIAogICJ0eXBlIjogInRscy1zbmktMDEiLCAKICAicmVzb3VyY2UiOiAiY2hhbGxlbmdlIgp9”,
“signature”: “c7FBXk4ZLdBxtBfPg7k1Ghu7h3TnGMrgzBN4_RhGhKZ83Yvo0_w2POh0mq2BCYb_i8HjRNZlX8IRpzCeggiwGTMkGq0YuqwL0eojI_cpqPmV8b_yKVQKGKqrv7Lpjvjtp4CpPa7udircHKO_iq7Eb5mLWH_pR2YAV6itmzgSEJ7J753juSyzJWK9uRLtgA-Fz95lV5SxVNIW1ojZpHL1g_8z3bgDhmASNwxvhjFnkGaVIU2nsfXg2zPxnQuH2zbwRF4aYZzSf19T49Fz2wj5g29R8U1c7zjm1FjNF6a82x2wO1hFMGvtKoRv4GcjUX1TC4FVUu95Uf27YFv-b3gZdQ”
}
“POST /acme/challenge/DHB3z49MRy-sOHZtgflZKdaZkDTqiYQdpUCwR5yHUjk/1119902566 HTTP/1.1” 202 339
Received response:
HTTP 202
Content-Length: 339
Boulder-Request-Id: Rerwy4T0u_L49bFsotUCsbxKqXkEK4tgzOoYK-YaYPc
Boulder-Requester: 6416818
Expires: Wed, 03 May 2017 14:28:58 GMT
Server: nginx
Connection: keep-alive
Link: https://acme-v01.api.letsencrypt.org/acme/authz/DHB3z49MRy-sOHZtgflZKdaZkDTqiYQdpUCwR5yHUjk;rel="up"
Location: https://acme-v01.api.letsencrypt.org/acme/challenge/DHB3z49MRy-sOHZtgflZKdaZkDTqiYQdpUCwR5yHUjk/1119902566
Pragma: no-cache
Cache-Control: max-age=0, no-cache, no-store
Date: Wed, 03 May 2017 14:28:58 GMT
Content-Type: application/json
Replay-Nonce: 3clRvFmGARKWHIV5ILOIwUWxIUofbKspxROACQL2Mag

{
“type”: “tls-sni-01”,
“status”: “pending”,
“uri”: “https://acme-v01.api.letsencrypt.org/acme/challenge/DHB3z49MRy-sOHZtgflZKdaZkDTqiYQdpUCwR5yHUjk/1119902566”,
“token”: “482mupyLCQvz-2Vuz6jtcOBZqlXuU88IsWXsUGExAL4”,
“keyAuthorization”: “482mupyLCQvz-2Vuz6jtcOBZqlXuU88IsWXsUGExAL4.M-D0FPuVtPZedbURF6AQ7cRQg3BF3WH9b7pnK-k5IbA”
}
Storing nonce: 3clRvFmGARKWHIV5ILOIwUWxIUofbKspxROACQL2Mag
Sending GET request to https://acme-v01.api.letsencrypt.org/acme/authz/DHB3z49MRy-sOHZtgflZKdaZkDTqiYQdpUCwR5yHUjk.
“GET /acme/authz/DHB3z49MRy-sOHZtgflZKdaZkDTqiYQdpUCwR5yHUjk HTTP/1.1” 200 1524
Received response:
HTTP 200
Content-Length: 1524
Strict-Transport-Security: max-age=604800
Boulder-Request-Id: lgwbNDOVWUvKftDLGYwCP8OhShhatckl88Z8o5yEafM
Expires: Wed, 03 May 2017 14:29:02 GMT
Server: nginx
Connection: keep-alive
Link: https://acme-v01.api.letsencrypt.org/acme/new-cert;rel="next"
Pragma: no-cache
Cache-Control: max-age=0, no-cache, no-store
Date: Wed, 03 May 2017 14:29:02 GMT
X-Frame-Options: DENY
Content-Type: application/json
Replay-Nonce: gwa4OQvVaPhCU6k0cYaRbfbcqQf0EOh6EJNAsfJ5DfQ

{
“identifier”: {
“type”: “dns”,
“value”: “cloud.moulard.org
},
“status”: “invalid”,
“expires”: “2017-05-10T14:28:54Z”,
“challenges”: [
{
“type”: “tls-sni-01”,
“status”: “invalid”,
“error”: {
“type”: “urn:acme:error:connection”,
“detail”: “Failed to connect to 84.39.33.18:443 for tls-sni-01 challenge”,
“status”: 400
},
“uri”: “https://acme-v01.api.letsencrypt.org/acme/challenge/DHB3z49MRy-sOHZtgflZKdaZkDTqiYQdpUCwR5yHUjk/1119902566”,
“token”: “482mupyLCQvz-2Vuz6jtcOBZqlXuU88IsWXsUGExAL4”,
“keyAuthorization”: “482mupyLCQvz-2Vuz6jtcOBZqlXuU88IsWXsUGExAL4.M-D0FPuVtPZedbURF6AQ7cRQg3BF3WH9b7pnK-k5IbA”,
“validationRecord”: [
{
“hostname”: “cloud.moulard.org”,
“port”: “443”,
“addressesResolved”: [
“84.39.33.18”
],
“addressUsed”: “84.39.33.18”
}
]
},
{
“type”: “http-01”,
“status”: “pending”,
“uri”: “https://acme-v01.api.letsencrypt.org/acme/challenge/DHB3z49MRy-sOHZtgflZKdaZkDTqiYQdpUCwR5yHUjk/1119902569”,
“token”: “5UjCMjdiveMZqvSKWMvKyR8xOxKvqr3FgzR-o5tFcG0”
},
{
“type”: “dns-01”,
“status”: “pending”,
“uri”: “https://acme-v01.api.letsencrypt.org/acme/challenge/DHB3z49MRy-sOHZtgflZKdaZkDTqiYQdpUCwR5yHUjk/1119902570”,
“token”: “oTJh018Mi8kNocmrPhHBzTAWxW_85UzWdsdPFPQ3ncM”
}
],
“combinations”: [
[
2
],
[
0
],
[
1
]
]
}
Reporting to user: The following errors were reported by the server:

Domain: cloud.moulard.org
Type: connection
Detail: Failed to connect to 84.39.33.18: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.
Cleaning up challenges
Exiting abnormally:
Traceback (most recent call last):
File “/usr/bin/certbot”, line 11, in
load_entry_point(‘certbot==0.11.1’, ‘console_scripts’, ‘certbot’)()
File “/usr/lib/python2.7/dist-packages/certbot/main.py”, line 882, in main
return config.func(config, plugins)
File “/usr/lib/python2.7/dist-packages/certbot/main.py”, line 608, in run
action, lineage = _auth_from_available(le_client, config, domains, certname)
File “/usr/lib/python2.7/dist-packages/certbot/main.py”, line 104, in _auth_from_available
renewal.renew_cert(config, domains, le_client, lineage)
File “/usr/lib/python2.7/dist-packages/certbot/renewal.py”, line 296, in renew_cert
new_certr, new_chain, new_key, _ = le_client.obtain_certificate(domains)
File “/usr/lib/python2.7/dist-packages/certbot/client.py”, line 265, in obtain_certificate
self.config.allow_subset_of_names)
File “/usr/lib/python2.7/dist-packages/certbot/auth_handler.py”, line 77, in get_authorizations
self._respond(resp, best_effort)
File “/usr/lib/python2.7/dist-packages/certbot/auth_handler.py”, line 134, in _respond
self._poll_challenges(chall_update, best_effort)
File “/usr/lib/python2.7/dist-packages/certbot/auth_handler.py”, line 198, in _poll_challenges
raise errors.FailedChallenges(all_failed_achalls)
FailedChallenges: Failed authorization procedure. cloud.moulard.org (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Failed to connect to 84.39.33.18:443 for tls-sni-01 challenge

Failed authorization procedure. cloud.moulard.org (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Failed to connect to 84.39.33.18:443 for tls-sni-01 challenge

IMPORTANT NOTES:

  • The following errors were reported by the server:

    Domain: cloud.moulard.org
    Type: connection
    Detail: Failed to connect to 84.39.33.18: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.
    root@cloud:~#

hi @gmoulard

When you create a post it’s a good idea to follow the format asked. The reason is that wading through a log file to get information such as your domain name is not a useful use of peoples time and may mean people are far less likely to help out.

I have renamed your post to what I believe the problem is will leave it to you to sort it out.

Usually I would have done more troubleshooting but most of my time was taken up reading the log (which was not a useful problem description)

Andrei

I have restored the original title, the "original" certificate status is not relevant for tls-sni-01. tls-sni-01 uses a self-signed, temporary certificate for validation.

The issue here is on the connection-level. Something weird is definitely going on here. While I can successfully request https://cloud.moulard.org through my browser and via curl, something rather odd is returned when I test the port via telnet:

telnet 84.39.33.18 443
Trying 84.39.33.18...
Connected to ip-84-39-33-18.rev.cloudwatt.com.
Escape character is '^]'.
SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.1

I'm not entirely certain where that SSH message is coming from, or if that's the reason, but I haven't seen anything like that before on a HTTPS server, so I guess it's possible that it's the reason the CA server fails to connect. I tested this from two connections and devices, so I don't think it's on my end.

1 Like

Maybe the server is using something like sslh to run SSH and HTTPS on the same port?

I’m not totally convinced that this will be compatible with the TLS-SNI-01 challenge.

2 Likes

can confirm there is a SSH listener on port 443 which is why telnet is returning an OpenSSH banner

@schoen are VHOST configs removed if the challenge fails? My thinking is that looking at the Apache Server is the next step

Andrei

There is a multiplexer of some kind that’s speaking both SSH and TLS on the same port. It seems to me that it’s at least partially time-based so that the SSH banner is sent after a delay if no TLS ClientHello is received.

@cpu @jsha, can you examine from server logs or you own understanding whether this multiplexer is likely to have caused a problem with completing a TLS-SNI-01 challenge? It looks to me like the TLS-SNI-01 certificate configuration was probably otherwise OK at the time the challenge would have been verified (unless the multiplexer itself is trying to terminate TLS sessions instead of passing them through to Apache, which I don’t think is happening here).

@gmoulard, is there a way that you can at least temporarily turn off the multiplexer application that is allowing both sshd and Apache2 to listen on the same port, and reserve the port exclusively for Apache2? It would be good to know whether this clears up the problem or whether you still get verification failures.

1 Like

Many many thank,

I have uninstall # apt-get remove sslh
and …

Congratulations, all renewals succeeded.

Perfect!!! Yours help is greatfull

Guillaume

1 Like

Sorry! I missed this mention. Looking at the logs I'd guess the failures were unrelated to sslh and probably a problem at a layer before that software. The connection failed messages don't match what I would expect to see if the problem were TLS/certificate related.

@cpu, that’s strange because @gmoulard said removing sslh made the problem go away. Perhaps there were two different problems producing different symptoms at different times?

@cpu, if you when you can read my log on : https://cloud.moulard.org/public/letsencrypt.zip
If you whan I can send other log.
G.

Very possible! If @gmoulard wants to restore sslh and do a more isolated test I'm happy to check the server side logs again.

@cpu and @schoen I hav’nt plan to restore sslh, but if you need, I can make it for you. Tell me if you have the utility that I reinstall sslh.
G.

@gmoulard, @cpu, @schoen,

Seems there is no problem with sslh. I’ve just created a VM (Debian Jessie), installed ssh, Apache and sslh. Configured ssh to listen on 127.0.0.1:22 and Apache on 127.0.0.1:80 and 127.0.0.1:443. Then configured sslh to listen on my public ip on port 443 and act as multiplexer for ssh and ssl.

I’ve created a simple Apache conf for domain sslh.sahsanu.com and then ran certbot-auto and it was able to get a certificate using tls-sni challenge.

# ./certbot-auto
Upgrading certbot-auto 0.12.0 to 0.14.0...
Replacing certbot-auto...
Creating virtual environment...
Installing Python packages...
Installation succeeded.
Saving debug log to /var/log/letsencrypt/letsencrypt.log

Which names would you like to activate HTTPS for?
-------------------------------------------------------------------------------
1: sub.otherdomain.tld
2: sslh.sahsanu.com
-------------------------------------------------------------------------------
Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter 'c' to cancel):2
Obtaining a new certificate
Performing the following challenges:
tls-sni-01 challenge for sslh.sahsanu.com
Waiting for verification...
Cleaning up challenges
Created an SSL vhost at /etc/apache2/sites-available/sslh.sahsanu.com-le-ssl.conf
Deploying Certificate for sslh.sahsanu.com to VirtualHost /etc/apache2/sites-available/sslh.sahsanu.com-le-ssl.conf
Enabling available site: /etc/apache2/sites-available/sslh.sahsanu.com-le-ssl.conf

Please choose whether HTTPS access is required or optional.
-------------------------------------------------------------------------------
1: Easy - Allow both HTTP and HTTPS access to these sites
2: Secure - Make all requests redirect to secure HTTPS access
-------------------------------------------------------------------------------
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 1

-------------------------------------------------------------------------------
Congratulations! You have successfully enabled https://sslh.sahsanu.com

You should test your configuration at:
https://www.ssllabs.com/ssltest/analyze.html?d=sslh.sahsanu.com
-------------------------------------------------------------------------------

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at
   /etc/letsencrypt/live/sslh.sahsanu.com/fullchain.pem. Your cert
   will expire on 2017-08-06. To obtain a new or tweaked version of
   this certificate in the future, simply run certbot-auto again with
   the "certonly" option. To non-interactively renew *all* of your
   certificates, run "certbot-auto renew"
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

So multiplexer was not an issue, at least for me is working fine.

Cheers,
sahsanu

2 Likes

@sahsanu, @cpu, @schoen,

I have re-install sslh on my VM. My Apache2 and sslh is restore, all is up and runing.
And my renews process still OK

root@cloud:/etc/apache2/sites-enabled# /usr/bin/letsencrypt

Saving debug log to /var/log/letsencrypt/letsencrypt.log

Which names would you like to activate HTTPS for?

1: cloud.moulard.org

Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter ‘c’ to cancel):
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
Cert not yet due for renewal

You have an existing certificate that has exactly the same domains or certificate name you requested and isn’t close to expiry.
(ref: /etc/letsencrypt/renewal/cloud.moulard.org.conf)

What would you like to do?

1: Attempt to reinstall this existing certificate
2: Renew & replace the cert (limit ~5 per 7 days)

Select the appropriate number [1-2] then [enter] (press ‘c’ to cancel): 2
Renewing an existing certificate
Performing the following challenges:
tls-sni-01 challenge for cloud.moulard.org
Waiting for verification…
Cleaning up challenges
Generating key (2048 bits): /etc/letsencrypt/keys/0005_key-certbot.pem
Creating CSR: /etc/letsencrypt/csr/0005_csr-certbot.pem
Deploying Certificate to VirtualHost /etc/apache2/sites-available/000-default-le-ssl.conf

Please choose whether HTTPS access is required or optional.

1: Easy - Allow both HTTP and HTTPS access to these sites
2: Secure - Make all requests redirect to secure HTTPS access

Select the appropriate number [1-2] then [enter] (press ‘c’ to cancel): 2
Enhancement redirect was already set.
Error while running apache2ctl graceful.
httpd not running, trying to start
Action ‘graceful’ failed.
The Apache error log may have more information.

(98)Address already in use: AH00072: make_sock: could not bind to address [::]:443
(98)Address already in use: AH00072: make_sock: could not bind to address 0.0.0.0:443
no listening sockets available, shutting down
AH00015: Unable to open logs

Rolling back to previous server configuration…
Error while running apache2ctl graceful.
httpd not running, trying to start
Action ‘graceful’ failed.
The Apache error log may have more information.

(98)Address already in use: AH00072: make_sock: could not bind to address [::]:443
(98)Address already in use: AH00072: make_sock: could not bind to address 0.0.0.0:443
no listening sockets available, shutting down
AH00015: Unable to open logs

IMPORTANT NOTES:

  • We were unable to restart web server
  • Congratulations! Your certificate and chain have been saved at
    /etc/letsencrypt/live/cloud.moulard.org/fullchain.pem. Your cert
    will expire on 2017-08-08. To obtain a new or tweaked version of
    this certificate in the future, simply run certbot again with the
    "certonly" option. To non-interactively renew all of your
    certificates, run "certbot renew"
    root@cloud:/etc/apache2/sites-enabled#
2 Likes

It’s pretty odd that it worked given the port binding error! I would expect the port binding error to prevent the renewer from working.

Maybe there are two different copies of Apache installed on this system?

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