Authorizations valid for 30 days and no certs can be issued if key is compromised

[mkerai]

I have a general query on the workflow for forcing an issuance of a new certificate.

1. Day 1: I can successfully issue a certificate.
2. Day 2: The key gets compromised for one reason or another and revoke the cert and need to issue another certificate.
3. Generate a new CSR and a new KEY file and attempt issuing a new cert. No DNS challenge data comes back, presumably because the authorizations are still valid for a full 30 days.

Question: How then can a new certificate be issued within the 30 days, if the key is compromised with these same 30 days ?

=======================

domain: d.callidusondemand.com
Client : Ansible + acme_certificate_module

I've tested with the 'force' option in the ansible module as well as making sure the 'remaining_days' is higher than the cert_days.

https://docs.ansible.com/ansible/latest/collections/community/crypto/acme_certificate_module.html

=======================

    "msg": {
        "account_uri": "https://acme-v02.api.letsencrypt.org/acme/acct/425120090",
        "authorizations": {
            "d.callidusondemand.com": {
                "challenges": [
                    {
                        "status": "valid",
                        "token": "t3b6qA54EhOJYZaUdkmMb3NOdOv_XQbYZ5cJZchrjwQ",
                        "type": "dns-01",
                        "url": "https://acme-v02.api.letsencrypt.org/acme/chall-v3/83747764340/CREAWw",
                        "validated": "2022-03-02T23:32:43Z",
                        "validationRecord": [
                            {
                                "hostname": "d.callidusondemand.com"
                            }
                        ]
                    }
                ],
                "expires": "2022-04-01T23:32:44Z",
                "identifier": {
                    "type": "dns",
                    "value": "d.callidusondemand.com"
                },
                "status": "valid",
                "uri": "https://acme-v02.api.letsencrypt.org/acme/authz-v3/83747764340"
            }
        },
        "cert_days": 86,
        "challenge_data": {},
        "challenge_data_dns": {},
        "changed": true,
        "failed": false,
        "finalize_uri": "https://acme-v02.api.letsencrypt.org/acme/finalize/425120090/68283796850",
        "order_uri": "https://acme-v02.api.letsencrypt.org/acme/order/425120090/68283796850"
    }

[MikeMcQ]

A couple things

First, I think cert_days needs to be 1 to cause it to 'force' renew. That value is how many days the cert remains valid (I just looked at the ansible docs)

Two, yes, domain validations remain active for up to 30 days when reusing the same ACME account. It is not affected by the key or CSR used by the acme client.

[Rip]

Hi @mkerai and Welcome to the community.

@mkerai

general query

So I am a bit confused by what I am reading in your post.

1. Is this a hypothetical question?

I dont see any a records for the domain you posted....
I do see an MX record but not for the subdomain you mention...
Absolutely everything is timing out from where I am.

2. Were you actually able to obtain a certificate?
3. Was your certificate actually compromised?
4. Did you actually "revoke" the certificate?
5. If so, HOW did you revoke the certificate?

I see 2 certificates issued to d.callidusondemand.com on 3/2/2022

crt.sh | d.callidusondemand.com

There is more going on here than your inquiry implies. Would you be willing to give us more information? Frankly, I'm not the sharpest tool in the box, maybe someone else here is more familiar with ansible than I.

[mkerai]

cert_days is what LetsEncrypt returns back showing how many further days the cert is valid for. In the above example, 86 more days.

But I've revoked the cert and generated a new key/csr to attempt a new cert to be issued. ( NB: I'm simulating a compromised key situation)

[MikeMcQ]

@mkerai

cert_days is what

My reading of the ansible docs says it means how many days should ansible consider a cert valid before it tries to renew it. Some, even most, acme clients do not look at revocation status.

This is a common feature among all acme clients - ansible being just one. By setting it to 1, or maybe even zero, it would force ansible to try renewal.

Even if I misunderstand, it is easy to try since what you have done has not worked.

[mkerai]

1. It's hypothetical in the sense I'm testing on a real LetsEncrypted issued certificate.
2. Certificate was not compromised, but I'm simulating a loss of the key. I want to build a process/procedure where I want to know what happens IF the key gets compromised.
3. Yes, I revoked the certificate. ( community.crypto.acme_certificate_revoke ansible module ). The OCSP status @ crt.sh shows the state as 'Revoked'

They are not 2 certs, they are the same cert. Signatures etc are the same. I don't know though, why we have 2 crs.sh ID's though.

[MikeMcQ]

@mkerai

They are not 2 certs

No, you are right. One of them is a 'precert' and the other the 'leaf'. The 'leaf' is the actual cert.

[Rip]

OK so I am catching up with this. I see the status.
But there has to be a better way to test your workflow.

@mkerai

Certificate was not compromised, but I'm simulating a loss of the key.

So what exactly is your question and how do you expect us to help you?

[mkerai]

The question is as simple as how do I get a new certificate issued. My attempt at getting a new cert does not work because the authorization of the last cert is active for 30 days and the DNS challenges are both empty for the new cert attempt.

    "challenge_data": {},
    "challenge_data_dns": {},

[mkerai]

cert_days is a return value, not an input parameter we can set.

[schoen]

The ACME authorization there indicates, not that the old certificate is valid or exclusively valid, but that your account is (already) authorized to request certificates for a particular subject name. Do you not expect to be authorized that way? Is this ACME client unable to request certificates without performing challenge? (Is it hard-coded to make challenges mandatory in some way even when the certificate authority says they're not required?)

[mkerai]

You may be right with respect to the Authorization. I was under the impression this has something to do with Authorizations, but it does not look like it is.

I'm still trying to figure out why the dns challenges responses are coming back empty. I expect to be challenged again since it's a new key and csr.

[Osiris]

@mkerai

I expect to be challenged again since it's a new key and csr.

No, a (valid) authorization is coupled to an account and a specific hostname only. It does not have anything to do with the keypair of a previously issued certificate.

[9peppe]

@mkerai

I expect to be challenged again since it's a new key and csr.

If your certificate key gets compromised, there's no need.

It only makes sense to challenge you again if your account key gets compromised. But I'm not sure there's a way to revoke those.

[Osiris]

@9peppe

It only makes sense to challenge you again if your account key gets compromised. But I'm not sure there's a way to revoke those.

Revoking isn't possible I believe, but you can change the account key to a new one: RFC 8555 - Automatic Certificate Management Environment (ACME) It's also possible to deactivate an entire account: RFC 8555 - Automatic Certificate Management Environment (ACME) But that's not a good idea if e.g. rate limit exceptions are coupled to an account.

[9peppe]

Both these options look a lot like a revocation.

Probably the first is exploitable by an attacker that replaces a key on a compromised account.

But the second is really inconvenient if you have rate limit exceptions or accounturi in your CAA records.

[Osiris]

@9peppe

Both these options look a lot like a revocation.

I'm not sure if a previously used, but rotated key can be used for a second key rotation again. In that case, actual revocation would have made the second rotation impossible, but if Boulder allows an older key to be used for rotation again, you can't call it revocation.

[9peppe]

Yep. I didn't think of this.

[rg305]

A very terrible way of getting a new cert:

@mkerai

I've revoked the cert and generated a new key/csr to attempt a new cert to be issued.

[you should be using the staging/testing environment for such "testing"]

@mkerai

I'm still trying to figure out why the dns challenges responses are coming back empty. I expect to be challenged again since it's a new key and csr.

To reiterate: The (up to) "30 days" relates only to the ACME account and specific FQDN(s).
[changing the key/csr is irrelevant]

[petercooperjr]

@Osiris

I'm not sure if a previously used, but rotated key can be used for a second key rotation again.

In my experimenting some months ago, once an account key was rotated, there didn't seem to be any record of it in the CA's database anymore. You could use the old account key again on a different (or the same) account, or even get a certificate using it as the private key. But in practice, if you know your account key is compromised, but you rotate your account to a different key (before an attacker does!), then I don't think there's any action that needs to be taken to "revoke" the compromised account key. An attacker could create their own account using it, but I don't think they could do anything to your account with it since your account uses a different key now.