Are we heading to a Certificate-apocalypse?

Most engineers are probably aware of the shortening life span of TLS certificates. this year certificate maximum life drops from 398 to 200 days. But what may not have registered is that the roadmap sees the max certificate time will continue to half every year. This means that by 2029 certificate lifecycle will be down to 47 days (31 days (core duration) + core duration/2 days + 1 day). But before 2029, in less than six months we’ll see the current certificate durations half from 200 to 100 days. As with the 2026 change, the new limits come into effect on the 15th March. Which does create an odd situation where certificates issued on the 14th March will outlast certificates issued on the following day.

The addition of half the core duration period is to allow for the recovery from failures. as of 2029 the expectation is every month the certificates should be rotated.

https://blog.mp3monster.org/wp-content/uploads/2026/10/image-2.pngManual processes are unsustainableThis means that the rotation of certificates has got to be accelerated to be monthly, a velocity that is simply not practical to be done by hand. This means the deployment of certificates really needs to be automated. There are a number of frameworks and standards that support the distribution of certificates.

Perhaps the best known and leading solution has been ACME protocol working in conjunction with Let’s Encrypt CA. The least known is the use of OpAMP also supports certificate distribution. The following table shows the different standards that specifically address certificate management (CLM), some implementations are linked to a Certificate authority , others are not.

StandardSpecificationOpen-source implementationsCommercial implementationsACMERFC 8555Certbot (client), acme.sh (client), lego (client), step-ca (server), Boulder (server)DigiCert, Sectigo, GlobalSign, EJBCA EnterpriseCMP / CMPv3RFC 9810EJBCA Community, Bouncy Castle (library)EJBCA Enterprise, DigiCert Trust Lifecycle ManagerESTRFC 7030Cisco libEST (client/server library), EJBCA Community (edition-dependent)EJBCA Enterprise, DigiCertSCEPRFC 8894MicroMDM SCEP, EJBCA CommunityMicrosoft Intune, EJBCA Enterprise, DigiCertCMCRFC 5272Dogtag PKICommercial implementations are less prominent; verify explicit CMC support and supported operations with individual PKI vendorsTo understand the differences between the different standards, it is worth looking at the standards from the perspective of the operations that are needed to manage certificates.

FunctionACMECMPESTSCEPVendor
CLM APICertificate issuanceYesYesYesYesUsuallyCertificate renewalYesYesYesYesUsuallyCertificate revocationYesYesNo native operationLimitedUsuallyCA certificate rolloverLimitedYesYesLimitedVariesCentral certificate inventoryNoNoNoNoUsuallyOwnership / application mappingNoNoNoNoVariesPolicy managementLimitedLimitedLimitedLimitedUsuallyApplication deploymentNoNoNoNoVendor-specificApplication activationNoNoNoNoThrough integrationsDeployment verificationNoNoNoNoVariesYou’ll note that the deployment, activation and verification steps fall into the domain of vendor solutions, and are variable. However we can address such considerations in an open-source (or commercial) manner through tooling such as Puppet, Chef and certain payload types provided by OpAMP.

These CLM options aren’t the end of the story as you may wish to look more broadly at no just the request and distribution of certificates, but the mechanisms through which the certificate is stored, and there is an overlap with such management with keys as well as certificates. For example APIs may use keys of certificates to help verify authenticity of the request. This also extends to mTLS operations where the client needs certificate to verify the server requests. For example KMIP provides an interface that can support cryptographic object (keys, certificates (public, private, symmetric), secret data, PGP Keys).

StandardSpecificationOpen-source implementationsCommercial implementationsKMIPOASIS KMIPPyKMIP (Python client/server)HashiCorp Vault Enterprise, Thales CipherTrustPKCS#11PKCS#11 v3.1SoftHSM, OpenSCHashiCorp Vault Enterprise, Thales Luna HSMSCIMRFC 7644elimity SCIM (Go library)Microsoft Entra ID, OktaManaging the impactThere are several impacts that need to be considered:

tracking certificate expiry

Last mile from client deployer to server folder and any refresh nudge required

Tracking certificate expiryTraditionally certificate expiry management could be handled as a manual process – after all if you have a log of which systems had certificates then if you simply reviewed the list once a month, you could spot expiries with time to spare. Even if the certificate distribution process was automated across many nodes. This just isn’t going to work, and the contingency time incorporated into the certificate life is contracting. Rather than trusting to a tracker spreadsheet being managed we should really focus on actual certificate data. This points to having a means by which application observability has a reporting metric on when a certificate will expire (date or a number of days). The later will prove to be easier as a metrics measure, but the value needs to be in context of when the metric was collected.

Last mile challengeWhile automation frameworks like Certbot and step-ca can drive the certificate issuance. These processes get the certificate to the relevant server. But we still need to move the certificate intro the location the application expects the certificate to be, and do we need to nudge the server to reload the certificate? Certbot for example expects to have a script to trigger for this action. This can get a little messy to deploy and maintain, particularly if there are subtle variances in deployments (as a result of manual application deployment in legacy environments), configuration creep etc. One possible way to simplify this is to leverage the capabilities of environment scanners to locate apps and their configs. Then use that to drive the auto creation of that last mile.

Why the change?The history for the reduction has largely been driven by browser providers particularly Google and Apple, and their security concerns about the trustworthiness of the web’s public key infrastructure (PKI). Historically, certificates could remain valid for several years, creating a prolonged window of exposure if a private key was compromised, a certificate incorrect certificates being wrongly used (organization or domain information became outdated – fore example domain name changes, acquisition of services etc). Certificate revocation mechanisms, particularly CRLs and OCSP, have not proven to be reliable as a means of ensuring browsers quickly stop trusting compromised certificates. Shorter lifetimes reduce this exposure and encourage the automation of certificate management.

The driving of changes has shifted from browser providers unilaterally declaring they won’t trust certificates that are older than a certain age, to a more formalized process governed primarily by the CA/Browser Forum, (an independent body bringing together Certificate Authorities and browser vendors).

Useful resourcesA/Browser Forum — TLS Baseline Requirements, version 2.3.1 (4 October 2026), section 6.3.2. Authoritative current hard limits: 398 days before 15 March 2026; 200 days from that date; 100 days from 15 March 2027; 47 days from 15 March 2029. Section 1.1 and the revision history identify 1 July 2012 as the original effective date. https://cabforum.org/working-groups/server/baseline-requirements/requirements/

CA/Browser Forum — FAQ for Baseline Requirements. Historical summary of the 60-month limit from July 2012 and the 39-month general limit from April 2015. This is a historical source, not the current rule set. https://cabforum.org/faq-about-the-baseline-requirements/

CA/Browser Forum — Ballot 193: 825-day Certificate Lifetimes (17 March 2017). Establishes the March 2018 transition to 825 days; also records the preceding 39-month rule and the qualifying 60-month legacy exception through June 2016. The page contains amendment markup; read the replacement wording in context. https://cabforum.org/2017/03/17/ballot-193-825-day-certificate-lifetimes/

Apple — About upcoming limits on trusted certificates. Announces the 398-day maximum for public TLS server certificates issued on or after 1 September 2020 and explains its scope. This change originated in browser/platform trust policy. https://support.apple.com/en-us/102028

CA/Browser Forum — Ballot SC081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods (11 April 2025). Records the successful vote for the 2026–2029 reductions; source 1 confirms the resulting current requirements. The April milestone is the vote result, not the end of the subsequent intellectual-property review period. https://cabforum.org/2025/04/11/ballot-sc081v3-introduce-schedule-of-reducing-validity-and-data-reuse-periods/

IETF Datatracker — draft-barnes-acme-00 (28 January 2015). First revision of the ACME Internet-Draft, before working-group standardization. https://datatracker.ietf.org/doc/draft-barnes-acme/00/

Let’s Encrypt / ISRG — Entering Public Beta (3 December 2015). Announces public availability without invitations. https://letsencrypt.org/2015/12/03/entering-public-beta

Electronic Frontier Foundation — Announcing Certbot: EFF’s Client for Let’s Encrypt (May 2016). Explains the rename, the EFF home, and ACME-based issuance and configuration automation. https://www.eff.org/deeplinks/2016/05/announcing-certbot-new-tls-robot

Let’s Encrypt community — New name (Certbot) for Python Let’s Encrypt client (12 May 2016). Dated contemporary announcement linking to EFF’s announcement; supports the exact event date. https://community.letsencrypt.org/t/new-name-certbot-for-python-lets-encrypt-client/15688

RFC Editor — RFC 8555: Automatic Certificate Management Environment (ACME), March 2019. Standards-track specification, published as a Proposed Standard. https://www.rfc-editor.org/info/rfc8555/

ACME — RFC 8555: Automated Certificate Management Environment; supports automated certificate issuance, renewal and revocation.

CMP / CMPv3 — RFC 9810: Certificate Management Protocol; supports PKI enrolment and certificate lifecycle operations.

CMP over HTTP — RFC 9811: Defines HTTP transport for CMP messages.

EST — RFC 7030: Enrollment over Secure Transport; supports certificate enrolment and re-enrolment over HTTPS.

SCEP — RFC 8894: Simple Certificate Enrolment Protocol; commonly used for network devices.

CMC — RFC 5272: Certificate Management over CMS; supports certificate requests and management messages. Updated to — RFC 10002: Updated specification superseding RFC 5272.

KMIP 2.1 — OASIS KMIP 2.1 Specification: Key Management Interoperability Protocol; manages cryptographic keys, certificates and other cryptographic objects.

PKCS#11 3.1 — OASIS PKCS#11 3.1 Specification: Cryptographic Token Interface; standard API for accessing cryptographic hardware and software tokens.

SCIM 2.0 — RFC 7644: System for Cross-domain Identity Management; supports identity and account provisioning rather than certificate management.

SPIFFE — SPIFFE Specifications: Secure Production Identity Framework for Everyone; standardizes workload identity across heterogeneous systems.

X.509-SVID — X.509-SVID Specification: Defines X.509 certificates used for workload identity and authentication.

X.509 PKIX — RFC 5280: Defines the Internet X.509 public key certificate and Certificate Revocation List (CRL) profile.

CA/Browser Forum Baseline Requirements — Current Baseline Requirements: Industry requirements governing publicly trusted TLS certificate issuance, domain validation, security practices and maximum certificate validity periods.

#AI #certbot #certificates #Cloud #cybersecurity #Security #Technology #TLS

A critical PHP flaw, a database breach and certificate keys that were tiny numbers, within days. What is confirmed, and how to check if you are affected.

Three security stories broke within days of each other. PHP2Shell is a critical flaw in PHP itself, a database vendor disclosed a breach, and a certificate authority turned out to be signing with keys that were tiny numbers. They look unrelated, but they teach the same thing: finding weaknesses is getting cheaper, so what matters now is how fast you fix things and whether you know what you run.

PHP2Shell: patch PHP now, and check logs back to 17 October.

Secrets in code: scan your repositories and rotate what turns up.

Certificates: check whether any of yours chain to eMudhra.

Last checked 22 October 2026. These stories are still moving.

PHP2Shell: a flaw in the code under much of the web
On 21 October PHP shipped emergency fixes for two flaws, CVE-2026-109618 and CVE-2026-109619. Both score 9.2 on CVSS v4.0, and PHP says either can give an attacker remote code execution without logging in.

The bugs are in PHP core, not in a plugin, so any installation that serves web requests is at risk. That includes sites on WordPress, Drupal, Joomla and Magento, where researchers at Calif confirmed working attacks. The affected code goes back to PHP 5.4, released in 2012 (Tenable, BleepingComputer).

The part to plan around is timing. Amazon Threat Intelligence saw an exploitation attempt on 17 October, four days before the patch existed, and it advises starting any investigation from that date rather than from disclosure (Amazon).

The fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35 (Tenable). Branches 7.4 through 8.1 get no official release, only source backports from the PHP security team. Branches 5.4 through 7.3 are end of life and get nothing.

Cloudflare's CTO said the company rolled out WAF rules for the known attack routes to every customer, free plans included, but called them a stopgap and told people to patch (Tenable).

A database vendor breach, and the secrets problem
PingCAP, the company behind the TiDB database, disclosed on 19 October that an intruder had been in its systems between 9 September and 7 October. PingCAP blames stolen service account credentials. A group calling itself FulcrumSec says it found cloud keys sitting in PingCAP's own code repositories. The company hasn't confirmed that, so for now it is an allegation (Dark Reading).

Whatever happened at PingCAP, the wider pattern is well documented. GitGuardian counted about 29 million new hardcoded secrets on public GitHub in 2025, up 34% on 2024, and found that 32.2% of internal repositories held at least one (TechRadar). Those are the vendor's own measurements, but the direction is hard to dispute. A key in a repository works for anyone who can read that repository.

A signing key that was the number 4
Eight intermediate certificates from the Indian certificate authority eMudhra were protected by private keys so small that anyone could recover them from the public certificates in under a second. A proper key of this type is a random number more than 100 digits long. Scott Helme recovered one that was just 4, and others that were 56 and 115. Browsers and operating systems blocked the certificates within hours (Help Net Security).

One number going around is wrong. eMudhra has issued more than 60 million certificates in total, but that isn't how many are at risk. The company estimates about 30,000 customer certificates need replacing (Help Net Security). It traced the problem to a faulty script during a key ceremony in April 2025, which produced a second, weaker set of keys with labels similar to the good ones. Staff picked the wrong set. Nobody knows yet whether anyone used the keys before the report.

The lasting risk is outside the browser. Apps, servers and devices that never get revocation updates may still trust those certificates.

What links them
Two of the three were found by researchers who went looking, and looking keeps getting cheaper. The PostgreSQL project now plans to release version 19 on 19 November (postgresql.org). Committer Peter Eisentraut has said AI-assisted code review surfaced defects faster than developers could fix them, which led to several features being reverted (technology.org).

Credit the AI or credit plain research, the effect on a small team is the same. More problems get disclosed, faster, and attacks sometimes start before a patch exists. You can't read your way through that stream. You can shorten the gap between learning you're affected and being fixed, and you can keep an honest list of what you run. Patching on a schedule someone owns is much of what managed security covers.

Check whether you are affected
Most setups can get through this quickly, though scanning a large repository history takes longer. Every command below only reads information, so run them on servers you're allowed to inspect. If you're on managed hosting, jump to step 5.

Part 1: PHP2Shell
Step 1: find out whether you run PHP at all. Look at web servers, containers, hosting plans, and any WordPress, Drupal, Joomla or Magento site, including the old marketing site nobody owns anymore.

Step 2: get the version.

php -v
php -fpm -v # may be php-fpm8.3 -v on Debian or Ubuntu
dpkg -l | grep -i php # Debian, Ubuntu
rpm -qa | grep -i php # RHEL, Alma, Amazon Linux

In WordPress, open Tools, then Site Health, then Info, then Server. For containers, check the image tag you deploy from, then run php -v inside a running one.

Step 3: compare it with the fixed releases.

PHP 8.5 before 8.5.12, 8.4 before 8.4.27, 8.3 before 8.3.36, or 8.2 before 8.2.35: vulnerable. Upgrade to the fixed release.

PHP 7.4 to 8.1: no official release, only source backports from the PHP security team. Move to a supported branch.

PHP 5.4 to 7.3: end of life, no fix from the PHP project.

Step 4: check for a distribution backport before you panic. Linux distributions often patch a flaw without changing the version number, so an old-looking version may already be fixed. Search the package changelog for the CVE IDs.

apt changelog php8.3-fpm | grep -E "CVE-2026-109618|CVE-2026-109619"
rpm -q --changelog php | grep -E "CVE-2026-109618|CVE-2026-109619"

If the IDs show up, that package has the fix. If they don't and you're on one of the vulnerable versions in the list above, treat it as unpatched. Change the package name to match what step 2 showed.

Step 5: on managed or shared hosting you can't see the runtime, so ask your provider in writing which PHP versions are patched for CVE-2026-109618 and CVE-2026-109619, and when. Then switch your site to a patched version in the control panel.

Step 6: look for signs that someone got there first. Attempts began on 17 October, so search from then.

find /var/www -name ".php" -type f -newermt 2026-10-17
find /var/www -path "uploads" -name ".php"

The first command also lists files you deployed since then, so compare it against your deploy history and look for files you didn't deploy. The second should normally return nothing, since PHP files in upload folders are a classic sign of a planted web shell. Also scan web server logs for odd POST requests, and check for outbound connections from the web server that you don't recognise.

A WAF rule, including the free Cloudflare one, is a stopgap and doesn't prove you weren't hit. If you find something you can't explain, treat it as an incident and isolate the server before you clean it up.

How to read the result: if you don't run PHP, this one doesn't apply to you. If you run a fixed version, or a package whose changelog names both CVEs, you're patched from here on, but do step 6 anyway. Anything else is exposed until you upgrade.

Part 2: secrets in your code
Run a scanner over your repositories and their full history, because a deleted key still sits in old commits.

gitleaks git .

newer releases; older ones use:

gitleaks detect --source .
trufflehog git file://. --only-verified

Rotate anything it finds first and clean up#security #cybersecurity #php #certificates #software #coding #development #engineering #inclusive #community
PHP2Shell, a Breach and a Key Called 4: Are You Exposed?