How to sensibly automate EE certificate signed by ACMPCA

Terraform Providers AWS
1

Dear all, I recently started using AWS ACM Private CA ,

Say, If I created a SHORT_LIVED_CERTIFICATE CA yesterday, with this:

resource "aws_acmpca_certificate_authority" "subca" {
  type = "SUBORDINATE"

  certificate_authority_configuration {
    key_algorithm     = "RSA_4096"
    signing_algorithm = "SHA512WITHRSA"
    usage_mode        = "SHORT_LIVED_CERTIFICATE"

    subject {
      common_name = "my-subCA"
    }
  }
}
resource "aws_acmpca_certificate" "subca" {
  certificate_authority_arn   = aws_acmpca_certificate_authority.rootca.arn
  certificate_signing_request = aws_acmpca_certificate_authority.subca.certificate_signing_request
  signing_algorithm           = "SHA512WITHRSA"

  template_arn = "arn:${data.aws_partition.current.partition}:acm-pca:::template/SubordinateCACertificate_PathLen0/V1"

  validity {
    type  = "DAYS"
    value = 7
  }
}

then try to sign an EE cert using that CA today:

resource "aws_acmpca_certificate" "example" {
  certificate_authority_arn   = aws_acmpca_certificate_authority.subca.arn
  certificate_signing_request = tls_cert_request.ee_csr.cert_request_pem
  signing_algorithm           = "SHA256WITHRSA"

  template_arn = "arn:${data.aws_partition.current.partition}:acm-pca:::template/EndEntityCertificate/V1"

  validity {
    type  = "DAYS"
    value = 7
  }
}

It fails immediately, with:

Error: error issuing ACM PCA Certificates with Certificate Authority (arn:aws:....): ValidationException: The certificate validity specified exceeds the certificate authority validity

I believe the reason being, by today the CA only has 6-days left. If that’s the case, how we use this? Because whatever we do, even with a GENERAL_PURPOSE CA, it’s possible that by the time when we request for a cert, the CA doesn’t have that long to live. am I missing something here?

2

I don’t have much experience with AWS… but I do in terms of running your own CA in general, and normally you would create the CA itself with a long validity. Yes, your EE certificates will have short validity, but the CA itself should have long validity.

Normally when a SubCA is approaching expiry and still needs to be used, its operators will either replace it with a new SubCA, or replace its certificate with one that has been resigned with a longer validity - so that the SubCA in operation always maintains longer validity than the longest certificates it is expected to issue.

3

ACM works a bit different way I suppose: It doesn’t allow to sign a cert, even with a valid CA, if the EE certificate validity is longer than the remaining time on the CA.
Also, a general purpose ACMPCA, which can issue an EE cert valid for max13 months, costs $400 a month but Short Lived ones, which can do only a 7-day valid cert, are $50 a month. It’s an AWS related issue.

4

Yes, I did skim the relevant AWS docs before answering - I assumed that your

would be operating in general-purpose mode.

If you’re just running both root and subca in short-lived mode, then I have to ask… what benefit are you deriving from having a root and subordinate CA at all? The usual purpose of having a root and subordinate CA is to provide separation between the long-lived trust anchor, and the day to day operational CA.

If you don’t have a long-lived CA at all, what benefit is the multi-level CA hierarchy providing you? Have you ended up doing it that way, just because there’s so much literature out there calling it a best practice without explanation?

5

The rootca is log-lived but the subcas are not (in non-prod environment) and that mainly b’cuz of the costs. But it still wouldn’t matter how long is the CA’s actual validity period, if it doesn’t sign a EE cert with a validity, which is more than the remaining CA validity period.

e.g. you created a CA on 1st Jan 2023 with a two yrs. validity and you decided that all your EE certs to have 1 yr. validity. After that, any EE certs you create in 2023 all should be okay. Then in February 2024, you need to sign another new certificate and that time it will fail, as the existing CA is only valid for another 11 months and you asking for cert to be valid for 12 months - that’s where the issue is with ACM. It doesn’t matter how long is your CA’s actual validity is, sooner or later it will fail to sign new certs - that’s my understanding. I’d be extremely happy to be proven wrong.

6

I have never used this AWS feature so I might be wrong… but the documentation for the short-lived-certificate offering made it seem like the 7 day limitation only applies to the certificates signed by the short-lived CA. However, the short-lived sub-CA’s own CA certificate is going to be signed by the root CA. This suggests to me that whilst the EE certificates need to be short-lived, it should be fine to have the root CA give the short-lived sub-CA a long-lived CA certificate (several years).

Yes indeed, that is true. That’s why part of running any X.509 PKI long term is being able to rotate CAs. For the case of SubCAs this is relatively easy, as it just means obtaining a new SubCA certificate from the root CA.

In your example, the SubCA operator needs to approach the root CA operator every year, for a new SubCA certificate with extended validity so that the available duration for issuing EE certs remains above 12 months.

7

This is not something that is specific to AWS - a certificate is only valid if all members of a chain are valid, so trying to sign a certificate with a validity longer than something higher up the chain is either not possible or pointless (even if you did sign a child certificate with a 10 year validity it would still expire when the root CA expires, even if the child has a longer expiry date).

From the documentation (Managing the private CA lifecycle - AWS Private Certificate Authority) it looks like the root CA has a validity of 10 years from creation. So that is the upper limit for any certificate if you can issue, if paying for the “general” mode from AWS.

AWS seems to have a lower cost “short-lived mode” which can only issue certs lasting a maximum of 7 days. This is specifically designed for use cases which are fully automated, so having short expiries is not a huge problem - if the thing using the cert only lives for a few days and/or the certificate process is fully automatic the validity period doesn’t matter as much. This is similar to Lets Encrypt, which only issues 3 month certificates, because it should be fully automatic. There are security & performance advantages in having short lived certificates, but that mode is not a replacement for the more traditional “manually renew a cert once a year and update the app” type mode used with say a paid certificate from Verisign.