Accessing website on https fails on the first run when using On-Demand TLS

1. Caddy version (caddy version):

v2.0.0 h1:pQSaIJGFluFvu8KDGDODV8u4/QRED/OPyIR+MWYYse8=

2. How I run Caddy:

a. System environment:

Ubuntu 18.04 LTS

b. Command:

nohup caddy run --resume &

d. My complete Caddyfile or JSON config:

{
    email myemail@domain.com
    on_demand_tls {
        ask https://api-to-check-domain/isValid
    }
}

:443

tls {
    on_demand
}

root * /home/tripkindle
encode gzip zstd
try_files {path} {path}/ /index.html
file_server

3. The problem I’m having:

The issue is occurring when using tls on_demand, after I set the DNS records of a new domain pointing to my Caddy server. The first time I access that domain in Google Chrome browser Version 83.0.4103.116 (Official Build) (64-bit) I get an Invalid Certificate error which wouldn’t go away until I close Chrome. If I access it in an Incognito window or any other browser after the first time it works fine with no certificate error but the first time always results in an error.

The ask endpoint is a whitelist of domains allowed to connect to my Caddy server and does not include the Caddy server IP address.

4. Error messages and/or full log output:

2020/07/01 15:59:57 [INFO] Obtaining new certificate for shop2.tripkindle.com
2020/07/01 15:59:57 [INFO][shop2.tripkindle.com] Obtain certificate; acquiring lock...
2020/07/01 15:59:57 [INFO][shop2.tripkindle.com] Obtain: Lock acquired; proceeding...
2020/07/01 15:59:57 [INFO][shop2.tripkindle.com] Waiting on rate limiter...
2020/07/01 15:59:57 [INFO][shop2.tripkindle.com] Done waiting
2020/07/01 15:59:57 [INFO] [shop2.tripkindle.com] acme: Obtaining bundled SAN certificate given a CSR
2020/07/01 15:59:57 [INFO] retry due to: acme: error: 400 :: POST :: https://acme-v02.api.letsencrypt.org/acme/new-order :: urn:ietf:params:acme:error:badNonce :: JWS has an invalid anti-replay nonce: "0102lhk0BycYV0QMyGy0wiHvKNU8PBOp_kK-VvDHejd5kew", url: 
2020/07/01 15:59:58 [INFO] [shop2.tripkindle.com] AuthURL: https://acme-v02.api.letsencrypt.org/acme/authz-v3/5599549734
2020/07/01 15:59:58 [INFO] [shop2.tripkindle.com] acme: Could not find solver for: tls-alpn-01
2020/07/01 15:59:58 [INFO] [shop2.tripkindle.com] acme: use http-01 solver
2020/07/01 15:59:58 [INFO] [shop2.tripkindle.com] acme: Trying to solve HTTP-01
2020/07/01 15:59:58 [INFO][shop2.tripkindle.com] Served key authentication (HTTP challenge)
2020/07/01 15:59:58 [INFO][shop2.tripkindle.com] Served key authentication (HTTP challenge)
2020/07/01 15:59:58 [INFO][shop2.tripkindle.com] Served key authentication (HTTP challenge)
2020/07/01 15:59:59 [INFO][shop2.tripkindle.com] Served key authentication (HTTP challenge)
2020/07/01 16:00:02 [INFO] [shop2.tripkindle.com] The server validated our request
2020/07/01 16:00:02 [INFO] [shop2.tripkindle.com] acme: Validations succeeded; requesting certificates
2020/07/01 16:00:03 [INFO] [shop2.tripkindle.com] Server responded with a certificate.
2020/07/01 16:00:03 [INFO][shop2.tripkindle.com] Certificate obtained successfully
2020/07/01 16:00:03 [INFO][shop2.tripkindle.com] Obtain: Releasing lock
2020/07/01 16:00:03 http: TLS handshake error from 51.6.185.205:64514: remote error: tls: unknown certificate
2020/07/01 16:00:03 http: TLS handshake error from 51.6.185.205:64517: remote error: tls: unknown certificate
2020/07/01 16:00:03 http: TLS handshake error from 51.6.185.205:64518: remote error: tls: unknown certificate
2020/07/01 16:00:12 http: TLS handshake error from 51.6.185.205:64522: remote error: tls: unknown certificate
2020/07/01 16:00:12 http: TLS handshake error from 51.6.185.205:64523: remote error: tls: unknown certificate
2020/07/01 16:02:13 http: TLS handshake error from 51.6.185.205:64579: remote error: tls: unknown certificate
2020/07/01 16:02:13 http: TLS handshake error from 51.6.185.205:64580: remote error: tls: unknown certificate
2020/07/01 16:02:19 http: TLS handshake error from 51.6.185.205:64584: remote error: tls: unknown certificate
2020/07/01 16:02:19 http: TLS handshake error from 51.6.185.205:64585: remote error: tls: unknown certificate

5. What I already tried:

I’ve tried programmatically adding hosts with curl -X POST -H "Content-Type: application/json" -d '["beta1.tripkindle.com", "beta2.tripkindle.com"]' "http://localhost:2019/config/apps/http/servers/srv0/routes/0/match/0/host/..." but since I won’t have access to DNS records for my customers pointing to my Caddy server I am not sure if it will be a good practice to add domains before they point to my Caddy server.

6. Links to relevant resources:

Following from the discussion here - Dynamically adding multiple domains and its limit - #19 by sv6231

1 Like

I have added the IP address of the Ubuntu machine hosting Caddy to the whitelist of domains that the ask endpoint refers to and it seems to now work but can anyone confirm if that is the way it should be?

Which certificate was being presented to the browser that it didn’t trust the CA?

It showed the certificate for shop2.tripkindle.com itself and when I viewed more information it said certificate valid but the padlock sign was still replaced by Not Secure until I quit Chrome and started it again.

We already know that. :slight_smile: Do you have more information? Who was the issuer, what are the details about the certificate?

Sorry that wasn’t helpful earlier. I have tried it with another domain, hope this is helpful:

Well, all I can say is it looks like a bug in Chrome.

It wouldn’t surprise me, browsers do lots of convoluted things. If you’re testing something, almost always use curl or some other simple HTTP agent.

Alright, thank you so much! I’ve seen that placing the Caddy server IP in the whitelisted domain seemed to have an effect. I am testing it in the browser since the client entering their domain for us to support would try it in their browser first.

This looks like the same problem as Internal SSL "certificate is not standards compliant" on macOS - #3 by matt

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