Remove SSL for specific domain in on-demand TLS configuration

1. Caddy version (caddy version):

v2.1.1 h1:X9k1+ehZPYYrSqBvf/ocUgdLSRIuiNiMo7CvyGUQKeA=

2. How I run Caddy:

Caddy configuration is load from JSON file using the curl endpoint.

a. System environment:

AWS EC2 (Ubuntu 20.04)

b. Command:

curl localhost:2019/load -H 'Content-Type: application/json' -d @final_with_headers.json

c. Service/unit/compose file:

paste full file contents here

d. My complete Caddyfile or JSON config:

{
  "admin": {
    "disabled": false,
    "enforce_origin": true,
    "listen": ":2020",
    "origins": [
      "localhost:2020"
    ]
  },
  "apps": {
    "http": {
      "servers": {
        "srv0": {
          "listen": [
            ":443"
          ],
          "routes": [
            {
              "handle": [
                {
                  "handler": "headers",
                  "response": {
                    "set": {
                      "Referrer-Policy": [
                        "same-origin"
                      ],
                      "X-Content-Type-Options": [
                        "nosniff"
                      ],
                      "X-Frame-Options": [
                        "DENY"
                      ],
                      "X-Xss-Protection": [
                        "1; mode=block"
                      ]
                    }
                  }
                },
                {
                  "handler": "subroute",
                  "routes": [
                    {
                      "handle": [
                        {
                          "handler": "vars",
                          "root": "/var/www/html/frontend/dist/webapp/"
                        }
                      ]
                    },
                    {
                      "handle": [
                        {
                          "handler": "rewrite",
                          "uri": "{http.matchers.file.relative}"
                        }
                      ],
                      "match": [
                        {
                          "file": {
                            "try_files": [
                              "{http.request.uri.path}",
                              "{http.request.uri.path}/",
                              "/index.html"
                            ]
                          }
                        }
                      ]
                    },
                    {
                      "handle": [
                        {
                          "encodings": {
                            "gzip": {},
                            "zstd": {}
                          },
                          "handler": "encode"
                        },
                        {
                          "handler": "file_server",
                          "hide": [
                            "Caddyfile"
                          ]
                        }
                      ]
                    }
                  ]
                }
              ]
            }
          ]
        }
      }
    },
    "tls": {
      "automation": {
        "on_demand": {
          "ask": "https://app.example.io/custom-domain/ssl-allowed/"
        },
        "policies": [
          {
            "on_demand": true
          }
        ]
      }
    }
  }
}

3. The problem I’m having:

The domain link.example.com is pointed to the server. When visited, a request a sent to the TLS ask the endpoint to validate the SSL allowed request.

The response received is 200, but no SSL certificate is issued to the domain and the domain is not accessible.

When there is already an SSL certificate generated, how can I remove the SSL for this specific domain to generate a new SSL on request or generate an SSL manually for this domain?

4. Error messages and/or full log output:

No error message is received.

5. What I already tried:

6. Links to relevant resources:

Please upgrade to Caddy v2.3.0!

FYI, SSL is a deprecated term, it’s now “TLS certificates” :wink:

It’s unclear why that would be the case, you omitted parts of your config and didn’t share your logs. We need the full config and logs to be able to help you.

I have updated the question with the complete configuration. Not sure where to look for the logs.

If you installed Caddy with apt and running as a systemd service, then you can run journalctl -u caddy --no-pager | less to see your logs.

I used the following command

journalctl -u caddy --no-pager -f

And tried accessing the domain for which we are facing issue with the TLS and here is the log

Feb 17 06:54:01 ip-172-31-7-70 caddy[773]: 2021/02/17 06:54:01 [INFO] Obtaining new certificate for link.groupemutuel.ch
Feb 17 06:54:01 ip-172-31-7-70 caddy[773]: 2021/02/17 06:54:01 [INFO][link.groupemutuel.ch] Obtain certificate; acquiring lock...
Feb 17 06:54:01 ip-172-31-7-70 caddy[773]: 2021/02/17 06:54:01 [INFO][link.groupemutuel.ch] Obtain: Lock acquired; proceeding...
Feb 17 06:54:01 ip-172-31-7-70 caddy[773]: 2021/02/17 06:54:01 [INFO][link.groupemutuel.ch] Waiting on rate limiter...
Feb 17 06:54:01 ip-172-31-7-70 caddy[773]: 2021/02/17 06:54:01 [INFO][link.groupemutuel.ch] Done waiting
Feb 17 06:54:01 ip-172-31-7-70 caddy[773]: 2021/02/17 06:54:01 [INFO] [link.groupemutuel.ch] acme: Obtaining bundled SAN certificate given a CSR
Feb 17 06:54:01 ip-172-31-7-70 caddy[773]: 2021/02/17 06:54:01 [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: "01039YmpDhYxNp5BW9A5XZyjOw-exeeeabPjRoQ1sTMMwAI", url:
Feb 17 06:54:02 ip-172-31-7-70 caddy[773]: 2021/02/17 06:54:02 [INFO] [link.groupemutuel.ch] AuthURL: https://acme-v02.api.letsencrypt.org/acme/authz-v3/10936753254
Feb 17 06:54:02 ip-172-31-7-70 caddy[773]: 2021/02/17 06:54:02 [INFO] [link.groupemutuel.ch] acme: Could not find solver for: tls-alpn-01
Feb 17 06:54:02 ip-172-31-7-70 caddy[773]: 2021/02/17 06:54:02 [INFO] [link.groupemutuel.ch] acme: use http-01 solver
Feb 17 06:54:02 ip-172-31-7-70 caddy[773]: 2021/02/17 06:54:02 [INFO] [link.groupemutuel.ch] acme: Trying to solve HTTP-01
Feb 17 06:54:02 ip-172-31-7-70 caddy[773]: 2021/02/17 06:54:02 [INFO][link.groupemutuel.ch] Served key authentication (HTTP challenge)
Feb 17 06:54:02 ip-172-31-7-70 caddy[773]: 2021/02/17 06:54:02 http: TLS handshake error from 99.44.84.110:65356: EOF
Feb 17 06:54:03 ip-172-31-7-70 caddy[773]: 2021/02/17 06:54:03 [INFO][link.groupemutuel.ch] Served key authentication (HTTP challenge)
Feb 17 06:54:03 ip-172-31-7-70 caddy[773]: 2021/02/17 06:54:03 [INFO][link.groupemutuel.ch] Served key authentication (HTTP challenge)
Feb 17 06:54:03 ip-172-31-7-70 caddy[773]: 2021/02/17 06:54:03 [INFO][link.groupemutuel.ch] Served key authentication (HTTP challenge)
Feb 17 06:54:05 ip-172-31-7-70 caddy[773]: 2021/02/17 06:54:05 [INFO] Deactivating auth: https://acme-v02.api.letsencrypt.org/acme/authz-v3/10936753254
Feb 17 06:54:05 ip-172-31-7-70 caddy[773]: 2021/02/17 06:54:05 [INFO] Unable to deactivate the authorization: https://acme-v02.api.letsencrypt.org/acme/authz-v3/10936753254
Feb 17 06:54:05 ip-172-31-7-70 caddy[773]: 2021/02/17 06:54:05 [ERROR] error: one or more domains had a problem:
Feb 17 06:54:05 ip-172-31-7-70 caddy[773]: [link.groupemutuel.ch] acme: error: 403 :: urn:ietf:params:acme:error:caa :: CAA record for link.groupemutuel.ch prevents issuance, url:
Feb 17 06:54:05 ip-172-31-7-70 caddy[773]:  (challenge=http-01 remaining=[tls-alpn-01])
Feb 17 06:54:07 ip-172-31-7-70 caddy[773]: 2021/02/17 06:54:07 [INFO] [link.groupemutuel.ch] acme: Obtaining bundled SAN certificate given a CSR
Feb 17 06:54:07 ip-172-31-7-70 caddy[773]: 2021/02/17 06:54:07 [INFO] [link.groupemutuel.ch] AuthURL: https://acme-v02.api.letsencrypt.org/acme/authz-v3/10936756060
Feb 17 06:54:07 ip-172-31-7-70 caddy[773]: 2021/02/17 06:54:07 [INFO] [link.groupemutuel.ch] acme: use tls-alpn-01 solver
Feb 17 06:54:07 ip-172-31-7-70 caddy[773]: 2021/02/17 06:54:07 [INFO] [link.groupemutuel.ch] acme: Trying to solve TLS-ALPN-01
Feb 17 06:54:08 ip-172-31-7-70 caddy[773]: 2021/02/17 06:54:08 http: TLS handshake error from 127.0.0.1:39196: EOF
Feb 17 06:54:08 ip-172-31-7-70 caddy[773]: 2021/02/17 06:54:08 [INFO][link.groupemutuel.ch] Served key authentication certificate (TLS-ALPN challenge)
Feb 17 06:54:08 ip-172-31-7-70 caddy[773]: 2021/02/17 06:54:08 [INFO][link.groupemutuel.ch] Served key authentication certificate (TLS-ALPN challenge)
Feb 17 06:54:11 ip-172-31-7-70 caddy[773]: 2021/02/17 06:54:11 [INFO] Deactivating auth: https://acme-v02.api.letsencrypt.org/acme/authz-v3/10936756060
Feb 17 06:54:11 ip-172-31-7-70 caddy[773]: 2021/02/17 06:54:11 [INFO] Unable to deactivate the authorization: https://acme-v02.api.letsencrypt.org/acme/authz-v3/10936756060
Feb 17 06:54:11 ip-172-31-7-70 caddy[773]: 2021/02/17 06:54:11 [ERROR] error: one or more domains had a problem:
Feb 17 06:54:11 ip-172-31-7-70 caddy[773]: [link.groupemutuel.ch] acme: error: 403 :: urn:ietf:params:acme:error:caa :: CAA record for link.groupemutuel.ch prevents issuance, url:
Feb 17 06:54:11 ip-172-31-7-70 caddy[773]:  (challenge=tls-alpn-01 remaining=[])
Feb 17 06:54:13 ip-172-31-7-70 caddy[773]: 2021/02/17 06:54:13 [ERROR] attempt 1: [link.groupemutuel.ch] Obtain: [link.groupemutuel.ch] error: one or more domains had a problem:
Feb 17 06:54:13 ip-172-31-7-70 caddy[773]: [link.groupemutuel.ch] acme: error: 403 :: urn:ietf:params:acme:error:caa :: CAA record for link.groupemutuel.ch prevents issuance, url:
Feb 17 06:54:13 ip-172-31-7-70 caddy[773]:  - retrying in 1m0s (12.167583883s/720h0m0s elapsed)...

Yep, that would explain it:

You’ll need to either remove the CAA record in the DNS zone for that domain, or change it to allow Let’s Encrypt as described in the above article.

I would recommend removing it, because then it would also allow issuance from ZeroSSL, which is another ACME CA that Caddy enables by default as of version 2.3.0. Issuer redundancy is good.

Hi Francis

I understand your point… But it easy to add CAA for Let’s Encrypt and ZeroSSL.
Provided you have control of your DNS records.

This example is from ZeroSSL (https://help.zerossl.com/hc/en-us/articles/360060119753-Invalid-CAA-Records)

Example #1:
Allow ZeroSSL certificates for site.com, including any subdomains as well as wildcards.

site.com. 3600 IN CAA 0 issue "sectigo.com"
site.com. 3600 IN CAA 0 issuewild "sectigo.com"

Yep you’re right @MagnuM2K, but in my opinion, CAA records are a bit of a speedbump that isn’t totally necessary. There’s some discussion here, I don’t think it’s that valuable, especially if you don’t understand what it does and are just blindly setting it according to some guide, but that’s just me:

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