could not get certificate from issuer

[gggitpl]

trafficstars

{
    "apps": {
        "http": {
            "servers": {
                "srv0": {
                    "automatic_https": {
                        "skip": [
                            "localhost"
                        ]
                    },
                    "listen": [
                        ":80",
                        ":443"
                    ],
                    "routes": [
                        {
                            "handle": [
                                {
                                    "handler": "reverse_proxy",
                                    "upstreams": [
                                        {
                                            "dial": "http://ngrokd"
                                        }
                                    ]
                                }
                            ],
                            "match": [
                                {
                                    "host": [
                                        "*.ngrok.xxx.com"
                                    ]
                                }
                            ],
                            "terminal": true
                        }
                    ]
                }
            }
        }
    }
}

 WARN    tls.issuance.zerossl    missing email address for ZeroSSL; it is strongly recommended to set one for next time
2021/12/22 03:24:39.920 INFO    tls.issuance.zerossl    generated EAB credentials       {"key_id": "sRiRccH4g1eioUzIdhVbJw"}
        2021/12/22 03:25:05.574 ERROR   tls.obtain      could not get certificate from issuer   {"identifier": "*.ngrok.xxx.com", "issuer": "acme.zerossl.com-v2-DV90", "error": "[*.ngrok.xxx.com] solving challenges: *.ngrok.xxx.com: no solvers available for remaining challenges (configured=[http-01 tls-alpn-01] offered=[dns-01] remaining=[dns-01]) (order=https://acme.zerossl.com/v2/DV90/order/I_NP7OKIso2RV765UZv_Ww) (ca=https://acme.zerossl.com/v2/DV90)"}
2021/12/22 03:25:05.578 ERROR   tls.obtain      will retry      {"error": "[*.ngrok.xxx.com] Obtain: [*.ngrok.xxx.com] solving challenges: *.ngrok.xxx.com: no solvers available for remaining challenges (configured=[http-01 tls-alpn-01] offered=[dns-01] remaining=[dns-01]) (order=https://acme.zerossl.com/v2/DV90/order/I_NP7OKIso2RV765UZv_Ww) (ca=https://acme.zerossl.com/v2/DV90)", "attempt": 2, "retrying_in": 120, "elapsed": 110.204531418, "max_duration": 2592000}

I am a newbie to caddy, hope to get any help, very grateful

[mholt]

No problem. For wildcard certificates you have to enable the DNS challenge. I'm mobile right now but there's a docs page about this.

@francislavoie @mohammed90 what if we have Caddy emit a warning if a wildcard domain is configured without the DNS challenge?

[gggitpl]

are there any examples

[mholt]

This wiki article has a tutorial: https://caddy.community/t/how-to-use-dns-provider-modules-in-caddy-2/8148?u=matt

[mohammed90]

@francislavoie @mohammed90 what if we have Caddy emit a warning if a wildcard domain is configured without the DNS challenge?

Not too unreasonable. Should it be just warning though? We know it'll fail to obtain cert anyways, so shouldn't we error out the config? Such config never worked anyways, so I doubt it's breaking anybody.

[mholt]

I like the idea of an error, but... well, the reason the DNS challenge is needed for wildcards in the first place is because of CAB forum policies, nothing technical... so like, a private CA could totally issue a wildcard cert with any challenge type they want. We could try to make it an error only if it's a public CA, but the lines get fuzzy here really fast, just for a "helpful" message too.

So, I mean, I would opt for an error instead, but I'm not sure what that logic looks like of "are we going to try to violate CAB BRs or do they not apply in this case?"

[mohammed90]

Oh, I skimmed the RFC of ACME and found it mentions the order with DNS challenge may set the wildcard field to true, but I didn't find the same notion for the HTTP challenge¹. That led me to believe it's enforced per the ACME protocol. I didn't know about the CAB forum vote until you mentioned it and I googled it. But you're right, a private CA may issue the certs if they please. But then the question comes: how can we distinguish those CAs as the population of ACME servers grows? Also, is it possible for the CAB forum to change the stance? If yes, then that change in stance forces us to cut new release for that change. A warning is less disruptive 😄 Should I create an issue to track it and label it good first issue? It shouldn't be too complex to implement.

¹ I'm not well versed in ACME protocol, so I might've misunderstood it. You'd know better.

[mholt]

Yep! That is 100% exactly my line of thinking too.

* I am not 100% clear as to why, but ACME separates the wildcard from identifers. The wildcard field is for prepending a * to the identifier: https://github.com/mholt/acmez/blob/6519778db58880455f6332c2024e4b15603c3f8e/acme/authorization.go#L72-L79

[mholt]

This is a little prickly, even for a warning. I'm going to wait and see if this is a common enough problem to warrant the effort for a warning.