ZeroSSL not working on domains without sub-domains

Help
1

1. The problem I’m having:

  1. I have a server that get requests from domains without “www.” and redirect them to a new server that handle the same domain with “www.”. So the main goal of this specific server it to make a redirect to the "www."domain.
    Everything is working good with “letsencrypt”, but when the server trying to use “zerossl” it gets errors all the time and can’t get a new certificate.

2. Error messages and/or full log output:

Sep 29 06:39:30 ip-10-0-1-67 caddy[374]: {"level":"debug","ts":1695969570.2362342,"logger":"events","msg":"event","name":"tls_get_certificate","id":"e6d50ac0-ca47-4ec3-b02c-028857fec9bb","origin":"tls","data":{"client_hello":{"CipherSuites":[4866,4867,4865,49196,49200,159,52393,52392,52394,49195,49199,158,49188,49192,107,49187,49191,103,49162,49172,57,49161,49171,51,157,156,61,60,53,47,255],"ServerName":"myexampledomain.com","SupportedCurves":[29,23,30,25,24,256,257,258,259,260],"SupportedPoints":"AAEC","SignatureSchemes":[1027,1283,1539,2055,2056,2057,2058,2059,2052,2053,2054,1025,1281,1537,771,769,770,1026,1282,1538],"SupportedProtos":null,"SupportedVersions":[772,771],"Conn":{}}}}
Sep 29 06:39:30 ip-10-0-1-67 caddy[374]: {"level":"debug","ts":1695969570.2363062,"logger":"tls.handshake","msg":"no matching certificates and no custom selection logic","identifier":"myexampledomain.com"}
Sep 29 06:39:30 ip-10-0-1-67 caddy[374]: {"level":"debug","ts":1695969570.2363138,"logger":"tls.handshake","msg":"no matching certificates and no custom selection logic","identifier":"*.com"}
Sep 29 06:39:30 ip-10-0-1-67 caddy[374]: {"level":"debug","ts":1695969570.2363183,"logger":"tls.handshake","msg":"no matching certificates and no custom selection logic","identifier":"*.*"}
Sep 29 06:39:30 ip-10-0-1-67 caddy[374]: {"level":"debug","ts":1695969570.239239,"logger":"tls","msg":"response from ask endpoint","domain":"myexampledomain.com","url":"https://www.admin-account-example.com/isDomainValid-nonWWW.asp?domain=myexampledomain.com","status":200}
Sep 29 06:39:30 ip-10-0-1-67 caddy[374]: {"level":"debug","ts":1695969570.2392607,"logger":"tls.handshake","msg":"all external certificate managers yielded no certificates and no errors","remote_ip":"206.189.57.110","remote_port":"36490","sni":"myexampledomain.com"}
Sep 29 06:39:30 ip-10-0-1-67 caddy[374]: {"level":"debug","ts":1695969570.2393742,"logger":"tls.handshake","msg":"did not load cert from storage","remote_ip":"206.189.57.110","remote_port":"36490","server_name":"myexampledomain.com","error":"no matching certificate to load for myexampledomain.com: open /var/lib/caddy/.local/share/caddy/certificates/acme.zerossl.com-v2-dv90/wildcard_.com/wildcard_.com.key: no such file or directory"}
Sep 29 06:39:30 ip-10-0-1-67 caddy[374]: {"level":"info","ts":1695969570.2393885,"logger":"tls.on_demand","msg":"obtaining new certificate","remote_ip":"206.189.57.110","remote_port":"36490","server_name":"myexampledomain.com"}
Sep 29 06:39:30 ip-10-0-1-67 caddy[374]: {"level":"info","ts":1695969570.2396588,"logger":"tls.obtain","msg":"acquiring lock","identifier":"myexampledomain.com"}
Sep 29 06:39:30 ip-10-0-1-67 caddy[374]: {"level":"info","ts":1695969570.2458105,"logger":"tls.obtain","msg":"lock acquired","identifier":"myexampledomain.com"}
Sep 29 06:39:30 ip-10-0-1-67 caddy[374]: {"level":"info","ts":1695969570.2459261,"logger":"tls.obtain","msg":"obtaining certificate","identifier":"myexampledomain.com"}
Sep 29 06:39:30 ip-10-0-1-67 caddy[374]: {"level":"debug","ts":1695969570.2459767,"logger":"events","msg":"event","name":"cert_obtaining","id":"75964cf8-e49f-4de4-b62f-65474cb1cdf1","origin":"tls","data":{"identifier":"myexampledomain.com"}}
Sep 29 06:39:30 ip-10-0-1-67 caddy[374]: {"level":"debug","ts":1695969570.2462652,"logger":"tls.obtain","msg":"trying issuer 1/2","issuer":"acme-v02.api.letsencrypt.org-directory"}
Sep 29 06:39:30 ip-10-0-1-67 caddy[374]: {"level":"info","ts":1695969570.2464483,"logger":"http","msg":"waiting on internal rate limiter","identifiers":["myexampledomain.com"],"ca":"https://acme-v02.api.letsencrypt.org/directory","account":"noam@admin-account-example.com"}

3. Caddy version:

v2.7.4

4. How I installed and ran Caddy:

a. System environment:

Ubuntu 22.04.3

d. My complete Caddy config:

{
        debug
        # TLS Options
        email noam@admin-account-example.com
        on_demand_tls {
                ask https://www.admin-account-example.com/isDomainValid-nonWWW.asp
        }
        # Disable redirect
        # auto_https disable_redirects
}
:443 {
        tls noam@camelengine.com {
                on_demand
        }
        redir http://www.{host}{uri}
}
:80 {
        redir http://www.{host}{uri}
}
2

That looks like half your logs – the half that is working as expected. Is there more? There’s nothing there indicating that ZeroSSL is even tried, or has an error.

3

Maybe this will help:


Sep 30 03:18:01 ip-10-0-1-67 caddy[374]: {"level":"debug","ts":1696043881.832145,"logger":"tls.obtain","msg":"trying issuer 2/2","issuer":"acme.zerossl.com-v2-DV90"}

Sep 30 03:18:01 ip-10-0-1-67 caddy[374]: {"level":"info","ts":1696043881.8327227,"logger":"http","msg":"waiting on internal rate limiter","identifiers":["user-domain-name.com"],"ca":"https://acme.zerossl.com/v2/DV90","account":"noam@myadminemail.com"}

Sep 30 03:18:01 ip-10-0-1-67 caddy[374]: {"level":"info","ts":1696043881.832841,"logger":"http","msg":"done waiting on internal rate limiter","identifiers":["user-domain-name.com"],"ca":"https://acme.zerossl.com/v2/DV90","account":"noam@myadminemail.com"}

Sep 30 03:18:01 ip-10-0-1-67 caddy[374]: {"level":"warn","ts":1696043881.8329782,"logger":"http.acme_client","msg":"HTTP request failed; retrying","url":"https://acme.zerossl.com/v2/DV90/newNonce","error":"performing request: Head \"https://acme.zerossl.com/v2/DV90/newNonce\": context deadline exceeded"}

Sep 30 03:18:01 ip-10-0-1-67 caddy[374]: {"level":"error","ts":1696043881.833088,"logger":"tls.obtain","msg":"could not get certificate from issuer","identifier":"user-domain-name.com","issuer":"acme.zerossl.com-v2-DV90","error":"[user-domain-name.com] creating new order: fetching new nonce from server: context deadline exceeded (ca=https://acme.zerossl.com/v2/DV90)"}

Sep 30 03:18:01 ip-10-0-1-67 caddy[374]: {"level":"debug","ts":1696043881.8332603,"logger":"events","msg":"event","name":"cert_failed","id":"04f890eb-0050-442b-9f73-8aac7784ac91","origin":"tls","data":{"error":{},"identifier":"user-domain-name.com","issuers":["acme-v02.api.letsencrypt.org-directory","acme.zerossl.com-v2-DV90"],"renewal":false}}

Sep 30 03:18:01 ip-10-0-1-67 caddy[374]: {"level":"error","ts":1696043881.8333066,"logger":"tls.obtain","msg":"will retry","error":"[user-domain-name.com] Obtain: [user-domain-name.com] creating new order: fetching new nonce from server: context deadline exceeded (ca=https://acme.zerossl.com/v2/DV90)","attempt":1,"retrying_in":60,"elapsed":179.998939402,"max_duration":2592000}

Sep 30 03:18:01 ip-10-0-1-67 caddy[374]: {"level":"info","ts":1696043881.8333173,"logger":"tls.obtain","msg":"releasing lock","identifier":"user-domain-name.com"}

Sep 30 03:18:01 ip-10-0-1-67 caddy[374]: {"level":"debug","ts":1696043881.833402,"logger":"http.stdlib","msg":"http: TLS handshake error from 20.120.74.197:9536: context canceled"}

Sep 30 03:18:01 ip-10-0-1-67 caddy[374]: {"level":"debug","ts":1696043881.8341722,"logger":"events","msg":"event","name":"tls_get_certificate","id":"94876cb5-d52b-40f3-98a6-2ec00179cea9","origin":"tls","data":{"client_hello":{"CipherSuites":[4866,4867,4865,49196,49200,163,159,52393,52392,52394,49327,49325,49315,49311,49245,49249,49239,49235,49195,49199,162,158,49326,49324,49314,49310,49244,49248,49238,49234,49188,49192,107,106,49267,49271,196,195,49187,49191,103,64,49266,49270,190,189,49162,49172,57,56,136,135,49161,49171,51,50,154,153,69,68,49159,49169,49160,49170,22,19,157,49313,49309,49233,156,49312,49308,49232,61,192,60,186,53,132,47,150,65,7,5,10,255],"ServerName":"gordion.se","SupportedCurves":[29,23,30,25,24],"SupportedPoints":"AAEC","SignatureSchemes":[1027,1283,1539,2055,2056,2057,2058,2059,2052,2053,2054,1025,1281,1537,771,515,769,513,770,514,1026,1282,1538],"SupportedProtos":["http/1.1"],"SupportedVersions":[772,771,770,769],"Conn":{}}}}
4

Oh, that just looks like the client is closing the connection before a certificate can be obtained. Since the client is no longer there, there is no reason to obtain a certificate. So the operation is aborted.

5

But I don’t understand it. Let encrypt create the certificate, but when I have to many request to them and Caddy call ZeroSSL it’s don’t create the certificate.
So what the different?
I like to remind that the main goal of this server is to redirect domains like my myexample.com to www.myexample.com
And the domain www.myexample.com is point to another server.
So how I can solve this issue?

6

Maybe the client is simply opening the connection and closing it before ZeroSSL has a chance to issue the cert.

How can we reproduce this to confirm?

7

No, it’s happening all the time, not only for one user. Any certificate from ZeroSSL is not created.
From Let’s Encrypt, the certificate is created all the time.
But when Let’s Encrypt got to 300 certificates per 3 hours it moved to ZeroSSL, and then the issue began.

I think because the server is doing a very fast redirect to “www.” and the “www.” is not on the same server, this is the lost connection of the user you’re mentioning.
But Let’s Encrypt handle it right and ZeroSSL no.

8

Ok, thanks for clarifying. Is this some behavior I could observe myself to troubleshoot? Unfortunately the domains have been redacted against our forum rules, so I can’t help.

I don’t think this makes sense to me, because the server can’t issue a redirect without establishing a TLS connection first.

9

Yes, sorry, I wanted to protect my clients privacy, so I needed to delete them.
I can’t give you an example because I’m returning to the old users every time I reach the Let’s Encrypt rate limit.

And for what you mention, I agree with you. It looks like ZeroSSL creates the SSL on the fly and redirects the user (because I don’t get an error page, and the redirect is happening).
But the issue is that it doesn’t save on the ZeroSSL folder.

Maybe this is the issue here.

10

No, sorry, I now see it doesn’t make the redirect.
It gives me an error on the https page and is not working.

11

Do you have a sponsorship with us? If so, I can offer support in private via email starting at the Indie Pro tier.

Otherwise, all I can do is guess at this point.

From the error message we know that 179.998939402 seconds have elapsed, which is 3 minutes. That’s a very long time :thinking: Since we’re only seeing excerpts of the logs instead of the whole logs for an entire handshake it’s again impossible to put the pieces together.

12

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