1year / 365 days cert ZeroSSL (aka Lifetime LifetimeDays variable)

[TiloGit]

Hi,

I'm using ZeroSSL cert for 3month cert with no issues. We change to paid account to use 1year cert. but we get this in the response when we try to get a 365 days valid cert:

error: No suitable certificate product is currently available to this account DEBUG: Response Code 401, Body:

{
    "detail": "No suitable certificate product is currently available to this account",
    "status": 401,
    "type": "urn:ietf:params:acme:error:unauthorized"
}

our call:

New-PACertificate 'myapp.dom1.com','dns2.mydom.com' -Plugin WebSelfHost -PluginArgs @{} -LifetimeDays 365

this overview said "Variable Cert Lifetime" not available at ZeroSSL for ACME but wonder where this info is coming from: https://poshac.me/docs/v4/Guides/ACME-CA-Comparison/#acme-spec-and-feature-support

[rmbolger]

Hi @TiloGit, thanks for reaching out. The information is coming from explicit testing I've done against the free ACME CAs. At the time I last tested, that particular feature which allows for sending a notBefore and notAfter value with a new order request was only supported by Google's CA.

I'm not sure about ZeroSSL, but for some of the other commercial CAs, there are different ACME endpoints for different products. Is there any documentation about using ACME for non-free certs from ZeroSSL? Or do you have to use their custom API instead of ACME?

[TiloGit]

Thx for the quick reply. The ZeroSSL ACME documentation is pretty "lean", nothing substantial https://zerossl.com/documentation/acme/

I got a support ticket open and keep you posted.

[TiloGit]

so far nothing out of ZeroSSL support or GH ticket. ZeroSSL gives same response with acme.sh, so it's not related to the PS script (https://github.com/zerossl/zerossl-bot/issues/41)

btw google allowed max 90 days cert (2184h),

{
    "detail": "Certificate lifetime: 8760h59m59.833192353s must not exceed the maximum allowed lifetime: 2184h",
    "requestID": "Xb--removed---7w",
    "type": "urn:ietf:params:acme:error:malformed"
}

and google didn't allow to start the 90 days later, (here try with --valid-from "+15d" acme.sh script

{
    "detail": "Requested NotBefore timestamp: 2024-01-20T20:26:13+00:00 must be within [2024-01-05T18:26:15.139817746+00:00, 2024-01-05T20:26:15.139817746+00:00].",
    "requestID": "U5M--revmoed--edg",
    "type": "urn:ietf:params:acme:error:malformed"
}

[rmbolger]

That's actually really interesting that acme.sh doesn't work either because I thought it the ZeroSSL API instead of ACME by default now. And if anything, I would've thought their direct API would work.

But yeah, the lifetime limits on Google are still the same despite allowing for variable lifetimes. I think the intention with the feature was to make it easier to offer shorter than the default lifetimes because certain CA requirements change after you get under a certain lifetime threshold.

[rmbolger]

Out of curiosity and since you seem to be pretty confident in your ACME usage so far. Why the need for longer than 90 day certs? Are you not able to automate renewals?

[TiloGit]

we can automated the cert stuff on our end but the other end wants to do cert pinning so we like to use certs with longer lifetime.

I might settle on https://www.buypass.com/ as it has 180 days.

Btw ZeroSSL works totally fine on 90days cert. Just can't use ACME for 365 days cert on ZeroSSL it seems.

[TiloGit]

Got info back from ZeroSSL support:

Regarding ACME - it's currently limited to 90-day certificates. 1-year certificates cannot be issued via ACME.

[rmbolger]

Well that's lame of them.