ERR ts=1717164516.1400423 logger=tls.obtain msg=could not get certificate from issuer identifier=*.gnas.duckdns.org issuer=acme-v02.api.letsencrypt.org-directory error=HTTP 400 urn:ietf:params:acme:error:malformed - JWS verification error

Help
1

I get the above error on Wildcards when using the below Caddyfile.

Also when I clear the certs and redo the entire thing, I have observed this same error either happens with main domain gnas.duckdns.org or the Wildcard, based on whichever is releasing the lock first. So if the Wildcard is released the JWS error happens on Main Domain or Vise versa.

So either the Main domain is verified and works, while Wildcards show JWS errors
OR Wildcards work and main domain has this JWS error

{
	acme_ca https://acme-v02.api.letsencrypt.org/directory
	acme_dns duckdns secret-token
}

gnas.duckdns.org:443 {
	tls {
		dns duckdns secret-token
	}

	encode zstd gzip

	reverse_proxy 192.168.1.9:80
}

*.gnas.duckdns.org:443 {
	tls {
		dns duckdns secret-token
	}

	encode zstd gzip

	@files host files.gnas.duckdns.org
	handle @files {
		reverse_proxy 192.168.1.9:8081
	}

	@tv host tv.gnas.duckdns.org
	handle @tv {
		reverse_proxy 192.168.1.9:8989
	}

	@dash host dash.gnas.duckdns.org
	handle @dash {
		reverse_proxy 192.168.1.9:8090
	}

	@ssh host ssh.gnas.duckdns.org
	handle @ssh {
		reverse_proxy 192.168.1.9:3000
	}

	@vault host vault.gnas.duckdns.org
	handle @vault {
		reverse_proxy vaultwarden:80
		# reverse_proxy /notifications/hub vaultwarden:3012
	}

	@notes host notes.gnas.duckdns.org
	handle @notes {
		reverse_proxy 192.168.1.9:22300
	}

	@movies host movies.gnas.duckdns.org
	handle @movies {
		reverse_proxy 192.168.1.9:7878
	}

	@subs host subs.gnas.duckdns.org
	handle @subs {
		reverse_proxy 192.168.1.9:6767
	}

	@docks host docks.gnas.duckdns.org
	handle @docks {
		reverse_proxy 192.168.1.9:9000
	}

	# @speedtest host speedtest.gnas.duckdns.org
	# handle @speedtest {
	#     reverse_proxy 192.168.1.9:49159
	# }

	@flare host flare.gnas.duckdns.org
	handle @flare {
		reverse_proxy 192.168.1.9:8191
	}

	@torrents host torrents.gnas.duckdns.org
	handle @torrents {
		reverse_proxy 192.168.1.9:8080
	}

	@photos host photos.gnas.duckdns.org
	handle @photos {
		reverse_proxy 192.168.1.9:8089
	}

	@sync host sync.gnas.duckdns.org
	handle @sync {
		reverse_proxy 192.168.1.9:8384
	}

	@backup host backup.gnas.duckdns.org
	handle @backup {
		reverse_proxy 192.168.1.9:8200
	}

	@indexer host indexer.gnas.duckdns.org
	handle @indexer {
		reverse_proxy 192.168.1.9:9117
	}

	@monitor host monitor.gnas.duckdns.org
	handle @monitor {
		reverse_proxy 192.168.1.9:19999
	}

	@media host media.gnas.duckdns.org
	handle @media {
		reverse_proxy 192.168.1.9:8096
		# reverse_proxy 192.168.1.9:8920
		# reverse_proxy 192.168.1.9:7359
		# reverse_proxy 192.168.1.9:1900
	}

	# @adguard host adguard.gnas.duckdns.org
	# handle @adguard {
	#     reverse_proxy adguardhome:80
	#     reverse_proxy adguardhome:53
	#     reverse_proxy adguardhome:67
	#     reverse_proxy adguardhome:68
	#     reverse_proxy adguardhome:443
	#     reverse_proxy adguardhome:3000
	#     reverse_proxy adguardhome:853
	#     reverse_proxy adguardhome:784
	#     reverse_proxy adguardhome:8853
	#     reverse_proxy adguardhome:5443
	# }
}

adguard-gnas.duckdns.org:443 {
	tls {
		dns duckdns secret-token
	}

	encode zstd gzip

	reverse_proxy adguardhome:80
}
2

Paging @mholt who develops Caddy and might be able to help.

5 Likes
3

Thank you for paging Caddy dev, I have also posted the same on Caddy forums as I was not able to narrow now if the issue is happening on Caddy's end or Let's Encrypt.

Thanks again.

1 Like
4

duckdns used to only support one TXT record value at a time.

If that is still true then a normal wildcard request of the base name and its wildcard two TXT record values are required on the same record name. And so will fail just as you describe.

A work-around is to issue a cert with just one name and then request a cert with both names and use that. The first cert authentication is cached by Let's Encrypt and so only one new authentication is needed on the second cert.

Another solution is to use a different DNS provider that supports multiple values on the same TXT record (most do).

Here is one example of a past thread with this

5 Likes
5

Thank you so much, I would check it out.

However, I would like to mention that this same config worked for me for atleast 6 to 8 months without any issues, such issues I have started facing maybe since a month or 2.

So it seems it used to work before and now it has stopped. Maybe duckdns had some api changes so something, I'm still a noob learning stuff :stuck_out_tongue:

1 Like
6

Well, I think a client could do both the challenges one at a time. But e.g. Certbot doesn't do that (although not sure how the third party certbot-dns-duckdns would handle the challenges.. :roll_eyes:). But Caddy might trigger the challenges differently?

3 Likes
7

Oh right good point. Needs caddy expert to weigh in :slight_smile:

3 Likes
8

Thanks, I'll respond to OP's topic on the Caddy forums. This is a third-party plugin and service I'm not familiar with and, given this is an unusual error I suspect it has to do with that; but we'll try looking into it.

5 Likes
9

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