ZeroSSL certificate query API error after upgrade to Caddy v2.8.4

Hi !

1. The problem I’m having:

I’m having problem requesting a Zero SSL certificate via Caddy v2.8.4 (issue not present in Caddy 2.7.6).
The ZeroSSL API returns :

API error 2836: csr_cn_is_invalid

I believe it is related to Zerossl issuance error after upgrade to Caddy v2.8.0 - Help - Caddy Community.
I tested several domain names with length and characters and I was able to narrow a bit the issue.
It appears it only happens when the FQDN is longer than 64 characters : I can get a certificate for a FQDN of 64 characters long, but not 65.

In the logs below, I put a default example domain name, but of course it happens with real ones.
The FQDN that fail respect the maximum number of labels and maximum number of characters for a label.

2. Error messages and/or full log output:

reverse-proxy_1  | {"level":"info","ts":1723555102.8689609,"logger":"tls.obtain","msg":"lock acquired","identifier":"ed1ee7f6-9fa3-464f-884e-b07f690cc0d6.mysubdomainexample.mydomain.com"}
reverse-proxy_1  | {"level":"info","ts":1723555102.8691015,"logger":"tls.obtain","msg":"obtaining certificate","identifier":"ed1ee7f6-9fa3-464f-884e-b07f690cc0d6.mysubdomainexample.mydomain.com"}
reverse-proxy_1  | {"level":"info","ts":1723555102.8701446,"logger":"tls.issuance.zerossl","msg":"creating certificate","identifiers":["ed1ee7f6-9fa3-464f-884e-b07f690cc0d6.mysubdomainexample.mydomain.com"]}
reverse-proxy_1  | {"level":"error","ts":1723555103.5465333,"logger":"tls.obtain","msg":"could not get certificate from issuer","identifier":"ed1ee7f6-9fa3-464f-884e-b07f690cc0d6.mysubdomainexample.mydomain.com","issuer":"zerossl","error":"creating certificate: POST https://api.zerossl.com/certificates?access_key=redacted: HTTP 200: API error 2836: csr_cn_is_invalid (details=map[]) (raw={\"success\":false,\"error\":{\"code\":2836,\"type\":\"csr_cn_is_invalid\"}} decode_error=json: unknown field \"success\")"}
reverse-proxy_1  | {"level":"error","ts":1723555103.5466719,"logger":"tls.obtain","msg":"will retry","error":"[ed1ee7f6-9fa3-464f-884e-b07f690cc0d6.mysubdomainexample.mydomain.com] Obtain: creating certificate: POST https://api.zerossl.com/certificates?access_key=redacted: HTTP 200: API error 2836: csr_cn_is_invalid (details=map[]) (raw={\"success\":false,\"error\":{\"code\":2836,\"type\":\"csr_cn_is_invalid\"}} decode_error=json: unknown field \"success\")","attempt":1,"retrying_in":60,"elapsed":0.677673042,"max_duration":2592000}
reverse-proxy_1  | {"level":"info","ts":1723555163.544303,"logger":"tls.obtain","msg":"obtaining certificate","identifier":"ed1ee7f6-9fa3-464f-884e-b07f690cc0d6.mysubdomainexample.mydomain.com"}
reverse-proxy_1  | {"level":"info","ts":1723555163.5449717,"logger":"tls.issuance.zerossl","msg":"creating certificate","identifiers":["ed1ee7f6-9fa3-464f-884e-b07f690cc0d6.mysubdomainexample.mydomain.com"]}
reverse-proxy_1  | {"level":"error","ts":1723555164.6836975,"logger":"tls.obtain","msg":"could not get certificate from issuer","identifier":"ed1ee7f6-9fa3-464f-884e-b07f690cc0d6.mysubdomainexample.mydomain.com","issuer":"zerossl","error":"creating certificate: POST https://api.zerossl.com/certificates?access_key=redacted: HTTP 200: API error 2836: csr_cn_is_invalid (details=map[]) (raw={\"success\":false,\"error\":{\"code\":2836,\"type\":\"csr_cn_is_invalid\"}} decode_error=json: unknown field \"success\")"}
reverse-proxy_1  | {"level":"error","ts":1723555164.6839156,"logger":"tls.obtain","msg":"will retry","error":"[ed1ee7f6-9fa3-464f-884e-b07f690cc0d6.mysubdomainexample.mydomain.com] Obtain: creating certificate: POST https://api.zerossl.com/certificates?access_key=redacted: HTTP 200: API error 2836: csr_cn_is_invalid (details=map[]) (raw={\"success\":false,\"error\":{\"code\":2836,\"type\":\"csr_cn_is_invalid\"}} decode_error=json: unknown field \"success\")","attempt":2,"retrying_in":120,"elapsed":61.818627261,"max_duration":2592000}

3. Caddy version:

Docker image : caddy/caddy:2.8.4-alpine
Caddy version inside image : v2.8.4 h1:q3pe0wpBj1OcHFZ3n/1nl4V4bxBrYoSoab7rL9BMYNk=

This issue presented here is not present on Caddy v2.7.6 and below

4. How I installed and ran Caddy:

a. System environment:

No relevant

b. Command:

docker-compose up reverse-proxy

c. Compose file:

volumes:
  reverse_proxy_data:
  reverse_proxy_config:

networks:
  rp:

services:
  reverse-proxy:
    image: caddy/caddy:2.8.4-alpine
    ports:
      - 80:80
      - 443:443
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - reverse_proxy_data:/data
      - reverse_proxy_config:/config
    environment:
      - PUBLIC_HOST=${PUBLIC_HOST}
      - ZEROSSL_API_KEY=${ZEROSSL_API_KEY}
    networks:
      - rp
  host
    image: mycustomimage:1.0.0
    networks:
      - rp

d. My complete Caddy config:

{
    cert_issuer zerossl {$ZEROSSL_API_KEY}
}

{$PUBLIC_HOST} {
    reverse_proxy http://host:3000
}

5. Links to relevant resources:

API Error Codes - ZeroSSL
Zerossl issuance error after upgrade to Caddy v2.8.0 - Help - Caddy Community

@Antonin I opened that issue and it’s still unsolved . But it doesn’t have to do anything with characters in my case … by any chance are you running your environment on arm architecture ? I feel its a golang related bug, haven’t reproduced the same on Intel yet.

Prior to Caddy v2.8.0, we used ACME with ZeroSSL. After v2.8.0, the zerossl issuer now uses ZeroSSL’s API instead. If you want to continue using ACME, you’ll need to set up acme_eab and use the acme issuer, configured to point to ZeroSSL’s endpoint https://acme.zerossl.com/v2/DV90

1 Like

Hi !
Thanks for the information.
Does it mean getting a ZeroSSL certificate via the API is not possible for a FQDN longer than 64 characters ?

I have no idea. You’d have to ask ZeroSSL support about that.

1 Like

Ok, does your previous answer was for my original post or for whizzygeeks ?
I’m not sure it was related, especially if you don’t know whether the ZeroSSL API has a character limit

Replying to you, yes. I don’t know the limitations of their API so you would need to ask them to clarify.

1 Like

Ok,

Prior to Caddy v2.8.0, we used ACME with ZeroSSL.

I understand this was the default behaviour.
I don’t find a way to access the documentation for a specific version, so does this mean we could not use ZeroSSL API at all for versions v2.7 and prior, or did we have to specify an option to be able to do so ?

Support simply did not exist for ZeroSSL’s API before 2.8.0, we only just implemented it recently. In theory it should have wider support than their ACME, is my understanding (but I don’t use ZeroSSL myself and I can’t speak on their behalf)

You can find more info in the release notes Release v2.8.0 · caddyserver/caddy · GitHub

1 Like

Thanks, it is way clearer now ! I read the release note earlier but was unsure about the behaviour.
Is there a way to print the full request done by Caddy, so that I have more information to contact ZeroSSL support ?
From what I can see with default logs, I just have the method (POST) and the endpoint but no parameters.

Hi,
After contacting the ZeroSSL support, we had confirmation that there is a 64 characters limit for a domain name when asking for a certificate with ZeroSSL API. This is expected behaviour and ZeroSSL won’t be able to change it in the future.

3 Likes

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