Added new root CA to sdt section

[ianedwards1]

Jira link

n/a

Change description

Added new digicert root CA to sdt section

Testing done

Security Vulnerability Assessment

CVE Suppression: Are there any CVEs present in the codebase (either newly introduced or pre-existing) that are being intentionally suppressed or ignored by this commit?

• Yes
• No

Checklist

• commit messages are meaningful and follow good commit message guidelines
• README and other documentation has been updated / added (if needed)
• tests have been updated / new tests has been added (if needed)
• Does this PR introduce a breaking change

Link to Terraform Plan

https://tfplan-viewer.hmcts.net/azure-platform-terraform/2693

🤖AEP PR SUMMARY🤖

• environments/test/apim_appgw_config.yaml:
  🔧 Updated root CA certificate name from civil_sdt_root_ca to civil_sdt_root_ca_2025 under the rootca_certificates section.

[github-actions]

Suggestions for Improvement

1. Naming Convention for Certificates:

   • Ensure the naming convention for the newly added rootca_certificate_name: civil_sdt_root_ca_2025 follows a consistent and descriptive format. For example, if adding a new expiration date for clarity, indicate this explicitly:
     yaml
     • rootca_certificate_name: civil_sdt_root_ca_exp_2025

2. Documentation:

   • Consider documenting the purpose of the new certificate directly within a comment above the addition for maintainability and clarity. For example:

     # Root CA certificate valid until 2025 for test environment
     - rootca_certificate_name: civil_sdt_root_ca_2025

3. Rotation Strategy:

   • Ensure that there is a certificate rotation strategy in place and document it as a process for the repository. This avoids potential downtime or security risks associated with expired certificates.

4. Validation:

   • Confirm the rootca_certificate_name value matches an existing certificate available in the infrastructure to avoid misconfigurations.

5. Environment-specific Configuration:

   • If this certificate addition is environment-specific, ensure the naming and configuration are properly abstracted for other environments. For example, introduce a variable at a higher configuration level if needed.

6. Future-proofing:

   • If certificates need frequent updates, consider externalizing rootca_certificate_name values into a separate configuration file or secret management service (e.g., Azure Key Vault) rather than hardcoding them.

Cost and Carbon Assessment

• Cost: No direct changes likely affecting costs.
• Carbon Usage: No discernible impact on carbon usage.

Implementing abstraction for certificates could slightly increase compute costs depending on the method used (e.g., queries to secrets management). Estimated impact might be negligible (≤ £1/month).

[paulridout]

Changes look OK.