cert-manager with ZeroSSL

[irbekrm]

ZeroSSL looks like an interesting alternative to LetsEncrypt We seem to be occassionally getting user questions about cert-manager with ZeroSSL (see i.e cert-manager#2882 and some questions on #cert-manager Slack). We could have a short tutorial / note on how to use cert-manager with ZeroSSL. It could be useful to also try it out ourselves, see if there are any potential issues etc.

[czomo]

Do you expect step by step instruction? I can do that. We are using ZeroSSL on production for some time.

[irbekrm]

Hi @czomo ,

Thank you for showing interest- a contribution would be very welcome!

Do you expect step by step instruction

It could be either a step-by-step tutorial, where you start with nothing and end up with an issued cert like https://cert-manager.io/docs/tutorials/venafi/venafi/ or a more brief note in FAQs with the ZeroSSL setup specific info (i.e that you'd need to use the external account binding)- perhaps whichever would have made more sense to you when you started?

[prashilgupta]

+1

[alikhil]

There is a tutorial in medium - https://medium.com/@markmcwhirter/alternative-acme-via-cert-manager-a9e9e7f105e0

[varac]

For anybody using ZeroSSL with cert-manager please also look into the discussion in https://github.com/jetstack/cert-manager/issues/2882 when you want to use the same EAB credentials on multiple clusters.

[antoninbas]

I keep getting context deadline exceeded errors when using ZeroSSL with cert-manager (when creating the issuer). After a long time, it can succeed if I am lucky.

I0113 01:52:19.149071       1 setup.go:219] cert-manager/controller/clusterissuers "msg"="ACME server URL host and ACME private key registration host differ. Re-checking ACME account registration" "related_resource_kind"="Secret" "related_resource_name"="zerossl-private-key" "related_resource_namespace"="cert-manager" "resource_kind"="ClusterIssuer" "resource_name"="zerossl-acme" "resource_namespace"="" "resource_version"="v1"
E0113 01:52:29.150124       1 setup.go:259] cert-manager/controller/clusterissuers "msg"="failed to register an ACME account" "error"="context deadline exceeded" "related_resource_kind"="Secret" "related_resource_name"="zerossl-private-key" "related_resource_namespace"="cert-manager" "resource_kind"="ClusterIssuer" "resource_name"="zerossl-acme" "resource_namespace"="" "resource_version"="v1"

Connecting to https://acme.zerossl.com/v2/DV90 seems super slow, so maybe that's the reason why. I wonder if it is always like this of if ZeroSSL is just having a bad day.

$ time curl https://acme.zerossl.com/v2/DV90
{
  "newNonce": "https://acme.zerossl.com/v2/DV90/newNonce",
  "newAccount": "https://acme.zerossl.com/v2/DV90/newAccount",
  "newOrder": "https://acme.zerossl.com/v2/DV90/newOrder",
  "revokeCert": "https://acme.zerossl.com/v2/DV90/revokeCert",
  "keyChange": "https://acme.zerossl.com/v2/DV90/keyChange",
  "meta": {
    "termsOfService": "https://secure.trust-provider.com/repository/docs/Legacy/20201020_Certificate_Subscriber_Agreement_v_2_4_click.pdf",
    "website": "https://zerossl.com",
    "caaIdentities": ["sectigo.com", "trust-provider.com", "usertrust.com", "comodoca.com", "comodo.com"],
    "externalAccountRequired": true
  }
}
real    0m6.990s
user    0m0.017s
sys 0m0.008s

Curious to see if others are experiencing the same issue.

[mhrabovcin]

I get the same context deadline exceeded error. The HTTP client used for connecting to ZeroSSL has timeouts set properly and these are not causing the timeout.

https://github.com/cert-manager/cert-manager/blob/d212165c8da228437e71a74c2e117ae9d62c7f24/pkg/acme/accounts/client.go#L51-L75

But the overall timeout to setup ClusterIssuer is hardcoded to 10s so if ZeroSSL endpoint is responding in a few seconds (within the HTTP client timeouts), the overcall context will cancel.

https://github.com/cert-manager/cert-manager/blob/d212165c8da228437e71a74c2e117ae9d62c7f24/pkg/controller/clusterissuers/sync.go#L44-L46

[KevinHosteur]

Hi it is possible to inscrease timeout next realise ?

[SgtCoDFish]

This is an issue on the cert-manager website, so it's not really the best place to get support on context deadline errors. I believe the feature request here is linked to the investigation in this comment where the 10s timeout was being hit.

It'd be nice to make that configurable, so I've created a cert-manager issue to track the feature request: https://github.com/cert-manager/cert-manager/issues/5080

[sossickd]

I keep getting context deadline exceeded errors when using ZeroSSL with cert-manager (when creating the issuer). After a long time, it can succeed if I am lucky.

I0113 01:52:19.149071       1 setup.go:219] cert-manager/controller/clusterissuers "msg"="ACME server URL host and ACME private key registration host differ. Re-checking ACME account registration" "related_resource_kind"="Secret" "related_resource_name"="zerossl-private-key" "related_resource_namespace"="cert-manager" "resource_kind"="ClusterIssuer" "resource_name"="zerossl-acme" "resource_namespace"="" "resource_version"="v1"
E0113 01:52:29.150124       1 setup.go:259] cert-manager/controller/clusterissuers "msg"="failed to register an ACME account" "error"="context deadline exceeded" "related_resource_kind"="Secret" "related_resource_name"="zerossl-private-key" "related_resource_namespace"="cert-manager" "resource_kind"="ClusterIssuer" "resource_name"="zerossl-acme" "resource_namespace"="" "resource_version"="v1"

Connecting to https://acme.zerossl.com/v2/DV90 seems super slow, so maybe that's the reason why. I wonder if it is always like this of if ZeroSSL is just having a bad day.

$ time curl https://acme.zerossl.com/v2/DV90
{
  "newNonce": "https://acme.zerossl.com/v2/DV90/newNonce",
  "newAccount": "https://acme.zerossl.com/v2/DV90/newAccount",
  "newOrder": "https://acme.zerossl.com/v2/DV90/newOrder",
  "revokeCert": "https://acme.zerossl.com/v2/DV90/revokeCert",
  "keyChange": "https://acme.zerossl.com/v2/DV90/keyChange",
  "meta": {
    "termsOfService": "https://secure.trust-provider.com/repository/docs/Legacy/20201020_Certificate_Subscriber_Agreement_v_2_4_click.pdf",
    "website": "https://zerossl.com",
    "caaIdentities": ["sectigo.com", "trust-provider.com", "usertrust.com", "comodoca.com", "comodo.com"],
    "externalAccountRequired": true
  }
}
real  0m6.990s
user  0m0.017s
sys   0m0.008s

Curious to see if others are experiencing the same issue.

Yes i am experiencing exactly the same issue, looks like there is an open PR to increase the timeout

[SudonymTM]

Same Issue here. Tomorrow we wanted to go live with 173 Domains and LE Rate-Limited me. Searched for an alternative, found one - and now this context-deadline throws me overboard...

[nik-nazarov]

same issue we have more than 200 domains and LE rate limited us: and zerossl cluster issuer failed with: Error initializing issuer: context deadline exceeded

curl -w "@curl.txt" -o /dev/null -s "https://acme.zerossl.com/v2/DV90"
time_namelookup:     0.011226s
time_connect:        0.060237s
time_appconnect:     0.173892s
time_pretransfer:    0.174196s
time_redirect:       0.000000s
time_starttransfer:  14.268732s
------------------------------
  time_total:        14.269133s

Environment details:: Kubernetes version: v1.21.4 cert-manager version: 1.8.0 Install method: helm chart

[SgtCoDFish]

For those who were experiencing context timeout issues, we've now published cert-manager 1.8.2 and cert-manager 1.7.3 which should address the issues you've been seeing!

Since this specific issue was originally intended to address how we document ZeroSSL on the website, I'll leave it open. But the underlying bug that people reported here is now fixed :+1:

[SgtCoDFish]

~Can you provide any details at all which might help us to debug what's going on for you?~

NOTE: this comment was in response to a now-deleted comment suggesting that the problem was still occurring. The user deleted their comment and replied below saying the problem was actually fixed for them.

[alikhanich]

Can you provide any details at all which might help us to debug what's going on for you?

Sorry for disinformation, pods stuck in pending state during update ><