Part of the Akamai WAF Defense Guide - Akamai WAF works as a proxy and as such needs valid certificates. Whilst the number of certificates may be relatively low, failure to renew causes significant outages. Missing domain names, ECC certificate compatibility, root CA selection - any of them being incorrect can cause problems. Automation ensures consistent renewals.

PKI Automation for Akamai: Why Edge Design Needs Certificate Automation

The Certificate Dependencies That WAF Deployment Reveals

Organizations deploy Web Application Firewalls for perimeter security. Implementation teams configure attack detection rules, tune false positive rates, integrate with security operations. Everything runs smoothly for ten months.

Then certificate expiration causes service outage and business losses.

WAF sits between clients and origin servers, evaluating every HTTPS connection. This creates certificate dependencies that impact high-value services:

Edge certificates - Presented to clients connecting to your services through Akamai. Must match public DNS names, comply with clients' configurations. This includes custom transport security for API access (e.g., mobile phone apps).

Origin certificates - Secure communication between Akamai edge nodes and origin servers. May use internal CA if edge-to-origin traffic stays within trusted infrastructure. You can even override default certificate validations to solve incidents (short-term) or create a security back-door.

Certificate validation - Akamai offers automated renewal using free CA Let's Encrypt. You have to build own configuration for other CAs that enterprises prefer.

Certificate rotation - It is easy to forget that not only certificates inside Akamai need to be renewed. The origin certificates cannot be scanned from outside so tools included in most products will fail to detect them. One option is to create procedures that renew both sets of certificates. Another is to deploy internal inventory and/or scanning capabilities that have access to applications protected by Akamai.

Manual certificate processes designed for quarterly renewal cycles can easily break when managing dozens of domains with edge protection. The operational debt compounds:

• There is not clear ownership of certificates in Akamai
• DevOps engineer manually requests certificate from IT team
• IT team validates request, generates certificate, emails file
• DevOps uploads to Akamai via Control Center
• Uploads to origin servers individually
• Validates connectivity still works
• Documents expiration date for next renewal

Process duration: 5-7 business days for single certificate. High risk of 'double request', when Akamai generates a new CSR while the first request is being processed. As a result, the certificate will be rejected by the Akamai platform.

At enterprise scale with hundreds of domains, multiple geographic deployments, and certificate validity periods decreasing from 398 days historically to 47 days by 2029¹, manual processes become increasingly risky and expensive.

Organizations don't discover this limitation during initial WAF deployment. They discover long after handovers to operational teams, when first renewal cycle creates operational crisis.

Why Certificate Validity Reduction Forces Automation

Certificate Authority Browser Forum (CA/Browser Forum) drives industry policy reducing maximum certificate validity:

Historical timeline:

• 2015: 5 years (1,825 days) maximum validity
• 2018: 2 years (825 days) maximum validity
• 2020: 13 months (398 days) maximum validity
• 2023: Industry discussion of 90-day maximum
• 2025 (April): Schedule for reducing validity approved
• Projected 2026 (March): 200 days
• Projected 2027 (March): 100 days
• Projected 2029: 47-day maximum validity¹

Operational impact of 47-day validity:

Organization managing 500 domains with staggered expiration:

• Renewals required: 7.5 per day (500 domains ÷ 47 days × 0.7 for renewal before expiration)
• Manual process time: 5 days per certificate
• Required staffing: 37.5 person-days of effort daily

This is obviously unsustainable. Certificate lifecycle automation transitions from operational improvement to business necessity.

Organizations deploying Akamai WAF without certificate automation discover the gap when renewal failures cause service outages. The security investment that should improve reliability instead introduces failure modes.

The ECC Certificate Compatibility Decision

Modern certificate standards support two cryptographic algorithms:

RSA (Rivest-Shamir-Adleman) - Industry standard since 1990s. Universal compatibility. Larger key sizes (2048-4096 bits) create computational overhead.

ECC (Elliptic Curve Cryptography) - Newer standard offering equivalent security with smaller keys. 256-bit ECC provides security comparable to 3072-bit RSA. Reduced computational cost, faster operations, smaller certificate size.

The compatibility trade-off:

Modern browsers and operating systems support ECC universally. Legacy systems, embedded devices, IoT infrastructure, and older server applications may not.

Critical question for Akamai deployment: Do your third-party integrations accept ECC certificates?

PQC Certificates: Whilst many companies struggle with ECC support, NIST as well as European Commission introduced timelines for post-quantum cryptography support.

Integration Compatibility Assessment

Enterprise customer integrations:

• Large corporations typically maintain modern infrastructure (ECC compatible) for browser-based applications. API-based services with 3rd party dependencies are often ignored
• Small businesses may use legacy systems (ECC support unclear)
• Government clients often require specific cryptographic standards (may mandate RSA)

Payment processors:

• Major providers (Stripe, Square, PayPal) support ECC
• Smaller regional processors may require RSA
• PCI-DSS compliance doesn't mandate specific algorithm (either acceptable)

Partner APIs:

• SaaS platforms generally ECC-compatible
• On-premise partner systems require individual validation
• Older enterprise middleware likely RSA-only

IoT device communication:

• Modern devices support ECC
• Legacy industrial equipment may require RSA
• Firmware update capability determines migration feasibility

In financial institutions, we discovered:

websites supported ECC without issues.

mobile phone app APIs, 3rd party integrations required RSA due to:

• Legacy payment processing infrastructure (scheduled for replacement)
• Partner loan broker using 8-year-old middleware (upgrade planned)

Decision: Issue ECC and RSA certificates as default (using Akamai platform). Maintain RSA certificates for specific exceptions requiring compatibility. Document exception list. Quarterly review to reduce RSA usage as partners modernize.

This required compatibility testing infrastructure to validate third-party integrations before production certificate rotation.

Root CA Selection and Trust Store Management

Automated certificate issuance requires selecting Certificate Authority:

Public CAs (Let's Encrypt, DigiCert, Sectigo, GlobalSign) - Broadly trusted by browsers and operating systems. Suitable for public-facing services. Certificate issuance subject to CA policies and validation requirements.

Private CAs (Internal PKI infrastructure) - Complete control over issuance policies. Suitable for internal services. Requires distributing root CA to all systems needing to trust certificates.

In both cases, they are ongoing replacements of old root CA certificates. It means that incidents due to clients using old lists of trusted root CAs are a constant risk as services need to change root CAs due to sunsetting by certificate issuers.

Akamai-specific consideration:

Akamai edge nodes must trust certificates presented by origin servers during edge-to-origin HTTPS connections. Options:

Option A: Public CA for origin certificates
Advantage: Akamai automatically trusts major public CAs
Disadvantage: External dependency, validation requirements, potential cost

Option B: Private CA for origin certificates
Advantage: Complete control, no external dependencies
Disadvantage: Must configure Akamai to trust your internal CA

Organizations frequently use hybrid approach:

• Edge certificates (client-facing): Public CA for maximum compatibility
• Origin certificates (edge-to-origin): Private CA for control and cost efficiency

This requires managing two distinct certificate hierarchies with different trust stores, validation procedures, and renewal mechanisms.

The Trust Store Distribution Challenge

Private CA deployment for origin certificates requires distributing root CA certificate to:

Akamai edge infrastructure - Configure origin server settings to trust your internal CA. Akamai provides interface for uploading custom CA certificates².

Origin servers - Must trust the same internal CA used to issue origin certificates (for certificate validation during health checks, internal service communication).

Monitoring systems - External uptime monitors, security scanners, performance testing tools must trust certificates or receive constant SSL validation errors.

Development environments - Engineers testing locally need CA certificates installed or encounter HTTPS errors during development.

Trust store management creates operational complexity. Certificate rotation at root CA level (rare but occasionally necessary) requires updating every system trusting that CA.

At the bank: We implemented automated trust store distribution using Ansible and a centralized distribution point. Root CA updates propagated automatically to all origin servers within maintenance windows. Reduced manual distribution from weeks to days or even hours.

Certificate Profile Configuration for Akamai

Akamai supports multiple certificate deployment models³:

Standard TLS - Shared certificate across multiple customers. Akamai manages certificate lifecycle. Least expensive option. Service accessed via Akamai-assigned domain (customer.akamaized.net).

Enhanced TLS - Shared infrastructure but custom certificate with your domains. Akamai manages renewal. Moderate cost. Service accessed via your branded domains.

CPS (Certificate Provisioning System) - Automated certificate management via API or Akamai Control Center. Supports third-party CA integration. It has a relatively complicated renewal process with several gates.

Critical configuration decisions:

1. Certificate Type Selection

Domain-validated (DV) - Automated validation via DNS or HTTP. Quick issuance (minutes). Suitable for most applications.

Organization-validated (OV) - CA verifies organization identity. Manual validation process (days). Required by some enterprise procurement policies.

Extended validation (EV) - Highest validation level. Displays organization name in browser. Expensive, slow issuance. Declining industry usage due to browser UI changes reducing visibility.

Bank selection: DV certificates for automated renewal. OV certificates for customer-facing primary domains where procurement policy required organization validation.

2. Subject Alternative Names (SANs)

Single certificate can protect multiple domains via SAN field:

Option A: Comprehensive certificate covering all domains
Advantage: Single certificate to manage
Disadvantage: Any domain addition/removal requires reissuing entire certificate

Option B: Service-specific certificates for related domains
Advantage: Changes isolated to affected services
Disadvantage: More certificates to track

Option C: Wildcard certificates covering *.example.com
Advantage: New subdomains automatically covered
Disadvantage: Security concern if private key compromised (affects all subdomains)

Organizations choose based on operational model. Mature certificate automation supports Option B (service-specific) because automation eliminates management overhead concerns.

3. Validity Period Strategy

Even before industry-wide reduction to 47 days, organizations choose shorter validity periods for security benefits:

90-day validity - Industry standard for automated systems (Let's Encrypt default)
30-day validity - Further exposure window reduction in case of a private key compromise
7-day validity - Extreme automation, minimal exposure window

Shorter validity requires more reliable automation. Organizations should demonstrate successful 90-day automation before attempting shorter periods.

Even when using certificates with 12 months' validity, you can introduce rotation with much shorter periods. If a new certificate successfully installs, you can revoke the old one. Public CAs charge per certificate-year so multiple renewals during year have often no impact on the cost.

The Serverless Certificate Automation Architecture

At the UK bank, we implemented serverless certificate lifecycle management coordinating Akamai edge protection with origin infrastructure:

Architecture Components

AWS Lambda functions handling:

Certificate request orchestration

• Monitors certificate expiration dates
• Initiates ACME protocol domain validation or uses enterprise CA account
• Coordinates DNS updates for validation challenges
• Retrieves issued certificates from CA

Akamai deployment

• Uploads certificates to Akamai via API
• Deploys to staging only so manual production change can be scheduled as required
• Validates edge deployment success
• Coordinates certificate activation across edge nodes

Monitoring and alerting

• Tracks certificate expiration
• Validates certificate chain correctness
• Alerts on validation failures or deployment errors

AWS services integration:

DynamoDB - Certificate inventory with metadata (domains, expiration dates, deployment status, CA used)

Secrets Manager - Secure storage for private keys, API credentials, CA authentication tokens

EventBridge - Scheduled triggers for expiration monitoring, renewal initiation

S3 - Certificate archive for audit trail and emergency recovery

CloudWatch - Logging, metrics, alarming for operational visibility

Workflow Automation

Normal renewal cycle (triggered 15 days before expiration):

1. Lambda checks DynamoDB for certificates expiring in 15 days it also checks Akamai for certificates within 'renewal window'
2. For each certificate, initiates CSR generation
3. Based on the type of validation, it facilitates necessary steps
4. Polls CA for validation completion
5. Retrieves issued certificate upon successful validation
6. Uploads certificate to Akamai via CPS API
7. Resolves warning from Akamai's certificates system (CPS)
8. Updates DynamoDB with new expiration date
9. Archives certificate in S3 for compliance

Cost efficiency:

Lambda execution: ~30 seconds per certificate renewal
Monthly executions: every hour -> 720 / month
Lambda cost: ~$0.1/month

Compared to manual process:
Previous cost: 5 person-days per certificate × 500 certificates/90 days × $400/day = $740/month in labor
Automation cost: $0.1/month
Cost reduction: 99.99%

The economic case is overwhelming once automation reaches production stability.

The Certificate Profile Decision Matrix

Organizations must decide certificate profiles before automation implementation:

Automated systems can support multiple profiles simultaneously. Legacy manual processes typically standardize on single profile for operational simplicity.

The automation investment enables profile diversity matching specific requirements rather than compromise.

What We Delivered at the Financial Institution

Initial state: Manual certificate requests via IT ticketing system. 5-7 day fulfillment time. Frequent expiration-driven outages. No inventory of active certificates.

Transformation deliverables:

Serverless automation platform - AWS Lambda orchestrating certificate lifecycle from request through deployment and monitoring.

Certificate inventory system - DynamoDB tracking all certificates with metadata enabling expiration monitoring and compliance reporting.

Dual-CA architecture - Public CA (Digicert) for edge certificates.

Profile flexibility - Both ECC and RSA certificates deployed as default. Automated testing validates integration compatibility before production rotation.

Akamai integration - API-driven certificate deployment eliminating manual Control Center interactions.

Compliance automation - Automatic archival of issued certificates, renewal logs, validation records for audit trail.

Timeline: 12 weeks from design to production automation handling first renewals.

Operational impact:

• Certificate renewal time: 5-7 days → 1 hour
• Manual effort per renewal: 2-4 hours → 0 hours
• Expiration-driven outages: 6-8 annually → 0 post-implementation
• Certificate inventory visibility: 0% → 100%

The WAF deployment that exposed certificate management gaps became the catalyst for PKI modernization delivering benefits beyond security.

Related Resources

• ← Back to Akamai WAF Defense Overview - Complete Akamai security guide
• ACME Certificate Automation → - Automated certificate management strategies
• PKI Implementation Guide → - Complete PKI transformation guide
• Certificate Outage Costs → - Impact of certificate failures
• Hidden Certificate Costs → - Operational overhead of manual management

References

1. Chrome Root Program. (2023). "Moving Forward, Together: Reducing Certificate Lifespans to 90 Days." Chromium Blog. https://blog.chromium.org/2023/11/reducing-tls-certificate-lifespans-to-90-days.html
2. Akamai Technologies. (2024). "Custom Certificate Authorities for Origin Servers." Akamai TechDocs. https://techdocs.akamai.com/property-manager/docs/custom-certs-origin
3. Akamai Technologies. (2024). "Certificate Provisioning System User Guide." Akamai Product Documentation. https://techdocs.akamai.com/cps/docs
4. Akamai Technologies. (2024). "CPS API Reference." Akamai API Documentation. https://techdocs.akamai.com/cps/reference/api
5. Let's Encrypt. (2024). "ACME Protocol Specification." Internet Security Research Group. https://letsencrypt.org/docs/acme-protocol-updates/
6. CA/Browser Forum. (2023). "Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates." https://cabforum.org/baseline-requirements-documents/
7. NIST. (2023). "Recommendation for Key Management." NIST Special Publication 800-57 Part 1 Revision 5.
8. AWS. (2024). "AWS Certificate Manager Documentation." Amazon Web Services. https://docs.aws.amazon.com/acm/
9. Mozilla. (2024). "Mozilla CA Certificate Policy." Mozilla Foundation.
10. Durumeric, Z., et al. (2013). "Analysis of the HTTPS Certificate Ecosystem." ACM Internet Measurement Conference.