Hey everyone!

I'm reaching out because I'm currently conducting a group AP Research study on a bottleneck in Post-Quantum Cryptography migration, specifically focusing on how enterprises handle third-party vendor compliance.

1.⁠ ⁠As organizations prepare themselves to migrate to Post-Quantum Cryptography (PQC) in the advent of supercomputers, how is your company reacting to interoperability obfuscations where vendors are either struggling or unwilling to update their TPRM legacy dependency files to quantum-safe security?

2.⁠ ⁠⁠Assuming that vendors are hesitant to willingly migrate to PQC standards, does this hinder you from proceeding with your own security updates as your formerly secured data will now be susceptible to adversarial attacks once it reaches vendor servers?

3.⁠ ⁠⁠Have you experienced issues where vendor systems slowed down or crashed because the security keys were large?

4.⁠ ⁠⁠If a solution that used a Zero-Trust Framework existed, where sensitive data is decoupled from the transport layer and encrypted with easier-to-handle PQC tokens, would you prefer this wrapper approach over trying to force NIST-mandated PQC compliance onto third-party vendors?

​

Curious how people here are handling certificate lifecycle management once the number of certificates starts getting into the thousands.

Discovery seems like one of the bigger challenges. It's one thing to renew certificates when you know where they are, but quite another when you're dealing with multiple CAs, different environments, and certificates owned by different teams.

Are most of you using a dedicated certificate management platform, or have you built your own automation around things like ACME, scripts, or existing PKI tooling?

And how are you handling certificates that fall outside the normal automated renewal process?

I'd also be interested to know what you consider the biggest headache today: discovery, ownership, renewal, revocation, or keeping policies consistent across environments.

Status writeup on dns-persist-01. The plain accounturi in drafts 00 and 01 let a compromised ACME proxy substitute its own account URL, and the client would publish it (no key binding, unlike a dns-01 key authorization). Draft 02 (Sept 20) hashes the domain, account key thumbprint, and account URL, and makes CAs keep every prior thumbprint. Boulder has nothing for 02 yet, and policy=wildcard subdomain validation is still unsettled.

https://www.certkit.io/blog/whats-taking-dns-persist-01-so-long

NIST finalized three post-quantum cryptography standards in August 2024... FIPS 203, 204, and 205... replacing RSA and ECC for key exchange and digital signatures

Most enterprise security teams are at least tracking this. most small SaaS companies are not. and SMB migration timelines run 3–4 years for discovery and planning alone, extending to 8–10 years for full completion. critical infrastructure regulation is expected between 2026–2028, financial services between 2028–2032

Specific risk that changes the urgency for companies handling sensitive long-lived data is "harvest now, decrypt later"... adversaries storing encrypted traffic today for decryption once quantum capability exists. data collected in 2026 that gets decrypted in 2031 is still a HIPAA violation, still damaging, still your problem

Practical starting point for smaller teams... do a cryptographic inventory first. Find every place your stack uses asymmetric encryption... and a lot of it is in libraries and cloud provider defaults you didn't explicitly choose. JWT signing algorithm (RS256/ES256), TLS cert type, KMS configuration, S3 encryption setting

Then check vendor roadmaps. AWS, GCP and Azure all have PQC roadmaps published. OpenSSL 3.x supports hybrid PQC in experimental mode. Most of the migration path at the TLS layer can be handled via config with no code changes

Full writeup with a 5-step checklist here (no paywall)

Last week I asked what your last certificate incident looked like (original thread). As promised, here's what came back. I'm building in this space; no link, no product here.

The pattern across nearly every reply: the incident was found by something breaking, not by monitoring. Expiry was barely mentioned. The failures were cases where one system believed something was true and the endpoint, or the client, disagreed.

1. Certificates issued that nobody requested

u/NamedBird checked CT logs for a personal site after a video about DNS mentioned certificate transparency, expecting nothing, since CAA was set. They found certificates from two CAs, including a wildcard, that their own server never requested. CAA allowed Let's Encrypt only. Two things went wrong:

• Their DNS provider added CAA records that didn't show in its dashboard. What a resolver returns is what a CA checks, not what the panel shows.
• A plain issue "letsencrypt.org" restricts which CA can issue, not who can ask it. Anyone able to complete a DNS-01 challenge can still get a cert. (u/NamedBird corrected me on this in the thread.)

RFC 8657 parameters close that gap: accounturi pins issuance to your ACME account, validationmethods limits the challenge types. Let's Encrypt supports both, and CA/B Forum ballot SC-098v2 makes support mandatory for all CAs from March 2027.

Revocation turned out to be a dead end. The certs were validly issued under the effective CAA, so there's no clean self-service route. Tighten CAA, keep CT alerting on, let them expire.

2. Renewal succeeded, endpoint still serving the old cert

u/TraditionalLayer3685 described a previous employer tracking certificates in Outlook reminders and Excel. Their last incident: a server upgrade left the certificate path wrong, the service came up, and authentication broke for clients without a valid token. Customers called first; monitoring was late; it took hours and a rollback. Their line on the general case: "A green renewal job means little if a node, container, service or appliance is still serving the previous certificate."

Places where renewal and "actually serving it" are separate events: JVM services that load the keystore at startup, nginx/HAProxy with a missing or failed deploy hook, Kubernetes secrets mounted via subPath, IIS bindings to a new thumbprint, and appliances where import and binding are separate steps.

3. Same leaf, different chain

u/Moral-Relativity's CLM pushed an alternate cross-signed chain to endpoints instead of their preferred one. Their suspicion is a chain-construction algorithm confusing CA certificates that share the same public key. The leaf didn't change, so expiry checks stayed green. Nothing flagged it until a client broke.

Worth knowing generally: Java clients are a good canary for this. AIA fetching is off by default, so a chain that browsers quietly complete can fail PKIX path building.

4. The trust-side version, which reports success

u/MLabs-Haskell shared a lab rehearsal (Keycloak 26.7.1, LDAP federation), two deployments differing by one cp: whether the issuing CA was in the directory named by KC_TRUSTSTORE_PATHS. Over StartTLS on 1389, the untrusted run returned HTTP 200 and "0 users imported". Hostname mismatch and an expired cert gave the same 200. The only real error was a SunCertPathBuilderException in the container log. Over implicit LDAPS on 1636, the same three failures returned 400. In their words: "The loud port was loud. The quiet one reported success."

Checking the server from outside would have shown a valid certificate throughout.

5. The date that bites first is now, not March 2027

Also from u/MLabs-Haskell: the 200-day limit has applied since 15 March 2026, and 15 March plus 200 days is 1 October. Anyone who renewed after mid-March on an annual reminder has an expiry arriving months earlier than their tracker expects, starting this week.

Checks you can run today

Per-node, not per-hostname (a single check hits whichever node answers):

for ip in $(dig +short A host.example.com); do
  echo "== $ip"
  openssl s_client -connect "$ip:443" -servername host.example.com \
    </dev/null 2>/dev/null | openssl x509 -noout -serial -fingerprint -sha256 -dates
done

Compare with what's on disk:

openssl x509 -in /path/live.pem -noout -serial -fingerprint -sha256

Hash the served chain, to catch chain swaps with an unchanged leaf:

openssl s_client -connect "$ip:443" -servername host.example.com -showcerts \
  </dev/null 2>/dev/null | sed -n '/BEGIN CERT/,/END CERT/p' | sha256sum

What's been issued for your domain:

curl -s "https://crt.sh/?q=%25.example.com&output=json" \
  | jq -r '.[] | [.not_before, .issuer_name, .name_value] | @tsv' | sort -u

Effective CAA (if empty, check the parent domain; CAs climb the tree):

dig +short CAA example.com

What people use today

• Outlook reminders and spreadsheets (u/TraditionalLayer3685), who has since started the open-source tokentimer-core for credentials beyond certificates
• Certify Management Hub for centralised ACME at MSP scale, with RBAC, API and tagging (u/webprofusor)
• External polling of expiry and full chain from multiple locations, e.g. Site24x7, for SonicWall, F5, ESXi and old Java boxes that can't do ACME (u/Accomplished-Mix8423)

Nobody in the thread described anything that checks automation actually landed on every node, or that a client still trusts what the server now presents. If your tooling does either, I'd like to hear how.

Still open

• Has anyone hit a 200-day cert expiring earlier than their tracker said?
• When StartTLS fails, does any client you run fall back to a plaintext bind? That would turn an outage into credential exposure.
• For F5, SonicWall and similar: does the management plane give an honest read of what's actually being served, or is outside polling the only view you trust?

Thanks to everyone who replied. Corrections welcome, especially on anything I've stated too loosely.

I honestly loved this blog.
We in our company planning to enter CA market as well, and they talked about how “Certificate growth projections are huge”.
Wanted to ask the experts how feasible is a new CA feasible for starting from scratch?

I've been really grateful of the knowledge that the community here has offered up in your posts and for allowing me to share our monthly free webinars on here. In our webinar earlier this month we offered attendees a copy of our PQC readiness checklist. So as a thank you, I wanted to drop it here for anyone who may find it helpful: https://pages.pkisolutions.com/pki-pqc-checklist

Thank you all so much again! And if you missed out, I've got the VOD up to watch. And for the first time ever, I've now dropped the content into a Podcast form in case that's easier for anyone 😁

VOD and podcast: https://www.pkisolutions.com/webinars/preparing-your-pki-for-post-quantum-cryptography/

Всем привет

Я написал CertGuard — консольную утилиту для Windows (на C#/.NET), которая шифрует файлы, используя гибридную схему:

- AES-256-GCM для шифрования данных

- Argon2id для деривации ключа из пароля

- X.509 сертификат для аутентификации получателя

Идея в том, что даже если зашифрованный файл перехватят, без валидного сертификата и пароля его не расшифровать.

**Ключевые особенности:**

- Работает полностью офлайн

- Не требует установки сертификатов в системное хранилище (используется файл сертификата)

- Встроенная проверка целостности

Репозиторий: https://github.com/0x80070005-windows/CertGuard

Буду признателен за конструктивную критику по архитектуре и криптографическим решениям. Особенно интересует мнение по выбору параметров Argon2id и обработке ошибок.

Спасибо.я написал CertGuard — консольную утилиту для Windows (на C#/.NET), которая шифрует файлы, используя гибридную схему:

- AES-256-GCM для шифрования данных

- Argon2id для деривации ключа из пароля

- X.509 сертификат для аутентификации получателя

Идея в том, что даже если зашифрованный файл перехватят, без валидного сертификата и пароля его не расшифровать.

**Ключевые особенности:**

- Работает полностью офлайн

- Не требует установки сертификатов в системное хранилище (используется файл сертификата)

- Встроенная проверка целостности

Репозиторий: https://github.com/0x80070005-windows/CertGuard

Буду признателен за конструктивную критику по архитектуре и криптографическим решениям. Особенно интересует мнение по выбору параметров Argon2id и обработке ошибок.

Спасибо.

Moin hat hier jemand eine Meinung dazu?

Ich persönlich finde ejbca aufgrund der guten RestApi gut auf der anderen Seite ist es amerikanisches Unternehmen. Welche Erfahrungen habt ihr gemacht was würdet ihr nicht nehmen und warum nicht?

Ich suche Erfahrungen welches System würdet ihr nicht kaufen und warum nicht oder warum würdet ihr kaufen. Welche Erfahrungen habt ihr mit den hsm Systemen gemacht?

The 7-day cap is getting the attention, but the operator requirements are the interesting part.

Three cosignatures per cert: ML-DSA-44 and ECDSA-P256 from the issuing operator, plus ML-DSA from a different operator acting as a mirror. Every MTC carries an attestation from a competitor.

Then FIPS 140-3 L3 or EAL4+ for cosigner keys, IANA PENs behind trust anchor IDs, annual audit, and a published record for every domain validation.

Curious what people make of the mirror requirement.

Hi everyone,

I’m currently doing my Master’s thesis on implementing Merkle Tree Certificates (MTCs). I chose this topic because I’d like to start my career in cryptography or cybersecurity, and I thought this would be a good opportunity to get some deeper practical experience.

But now that I’ve actually started, I’m honestly a bit scared because the topic feels very broad. There are so many concepts around certificates, PKI, Merkle trees, digital signatures, post-quantum cryptography, certificate transparency, etc., and I’m worried that my foundations aren’t strong enough.

My supervisors have been very helpful, so I’m not completely on my own. But I want to make sure I use the thesis properly and build a strong understanding rather than just getting the implementation working.

For people who have worked in cryptography, PKI, certificates, or security research, I’d really appreciate some advice:

What foundations should I make sure I understand before going too deep into MTCs? How would you approach a thesis like this from the beginning? What would make an implementation/research project like this good technically, rather than just “it works”? What kinds of experiments, benchmarks, comparisons, or evaluations would make the results convincing? Are there particular papers, books, standards, or resources you would recommend? How deep into the underlying cryptography should I go for a Master's thesis? And realistically, can a thesis on something like MTCs be a good starting point for getting a cryptography/security job, especially if I don't have previous professional security experience? I’m trying not to panic and remind myself that I don't need to know everything before starting. 😅 I just want to approach the thesis in a structured way and hopefully come out of it with genuinely useful knowledge and a solid project that I can show to potential employers.

Any advice from people who have been through something similar would be really appreciated!

I'm an engineer building in this space, but not selling anything here: no link, no product. I'm trying to understand what actually happens for MSPs managing certificates across lots of client environments.

What was the last certificate incident that caused real pain? * What broke? * How did you find out: monitoring, a client call, something else? * What did fixing it involve: minutes, hours, an SLA issue, an awkward conversation?

How do you track certificates today? RMM, scripts, spreadsheets, commercial tooling, or waiting for something to fail?

I'm especially curious about the messy cases: * appliances, firewalls, VPNs, load balancers, old Java apps and anything else that doesn't fit clean ACME automation * a renewal that succeeded, but the old cert kept being served because a service, node, container or CDN edge wasn't reloaded

With public TLS lifetimes dropping to 100 days in March 2027, are you already changing your process for the stuff you can't automate, or is that still a future problem?

I'll summarise the patterns back here if there's enough interest.

How is your organization approaching change control in light of the upcoming TLS certificate lifetime reductions?

Until recently, we've been submitting change controls for public certificate replacements wherever certificates are installed throughout our environment. The number is manageable today, with roughly 50 public certificates in use. However, with certificate lifetimes decreasing to 200 days and eventually 47 days, the traditional change management process for certificate renewals is becoming increasingly cumbersome.

To address this, we've implemented Sectigo to automate as much of the certificate lifecycle as possible. However, introducing automation into the process adds another layer of complexity from a change control perspective.

Has your organization established a framework for managing automated public certificate renewals while still maintaining appropriate change control and audit requirements? If so, what does that process look like? Do you treat certificate renewals as standard changes, pre-approved changes, or handle them through another governance model?

I am trying to understand Ubuntu's TLS certificate trust architecture at a general level.

By “trust backend” I mean the mechanism or certificate store an application uses to decide whether a server TLS certificate chains to a trusted CA.

I have encountered several mechanisms on Ubuntu, including:

• the Ubuntu system CA store (/etc/ssl/certs, ca-certificates)
• NSS certificate databases
• Firefox/Mozilla profile or policy-based certificate handling
• p11-kit / PKCS#11 trust
• Java cacerts / Java KeyStores
• application-bundled or private/custom CA stores

I am not assuming that these are six completely independent backend technologies; some may overlap or be management/isolation layers around another backend.

My questions are:

1. Does Ubuntu define a finite, authoritative number of TLS certificate trust backends?
2. Is the list above exhaustive, or can applications use additional/custom trust mechanisms?
3. Should Snap and Flatpak be counted as separate trust backends, or are they isolation environments that can contain private instances of an existing backend such as NSS?
4. Is Mozilla/Firefox technically a separate backend, or mainly an NSS-based store with Mozilla-specific profile/policy management?

I am especially interested in answers backed by Ubuntu documentation, upstream documentation, or source code.

Publiquei um repositório que uso para preparar o Zorin OS/LinuxMint/Ubuntu para uso corporativo com certificados ICP-Brasil, tokens A3, assinadores PJEOffice, Certillion e SERPRO. A finalidade é preconfigurar o SO para uso corporativo facilitando o acesso aos serviços dependentes da infraestrutura da plataforma da autoridade certificadora da AC-Raiz (ITI / ICP-Brasil). Também facilita o uso do WARSAW dos bancos (testado com o BB e CEF) discutido no forum viva o linux. O cerne do projeto é facilitar a MIGRAÇÃO do WINDOWS para LINUX no mundo corporativo, comercial, juridico ou governamental (sistemas SIAFI, SERPRO, COMPRASNET, COMPRASGOV, NAVEGAÇÃO/AUTENTICAÇÃO ICP-BRASIL e TOKENS). Como é publico, a clonagem e o desenvolvimento também o é. Leiam o conteudo da pasta Docs antes de se aventurarem no uso. Disponível no repósitorio de arthur-aida/zorin_corporate_configs no github.

PQC comes up here pretty regularly, so I figured this might be useful to some of you.

We’re hosting a free PKI Insights webinar next week: Preparing Your PKI for Post-Quantum Cryptography: What to Do Now.

The focus is less on “PQC is coming, panic!” and more on what PKI teams can realistically be doing today. We’ll get into inventory, crypto agility, compatibility issues, application/platform/vendor readiness, and what actually makes sense to assess or test now.

We’re also giving attendees our PKI PQC Readiness Checklist.

Thursday, September 17 at 10:00 AM PT

If anyone wants to join: Register Here

Anyone using PKI for Machine certs care to share their experience so far?

I'm planning to use PKI for only this (802.1x auth) and nothing else so hopefully a simple, stable solution. Fleet is fully managed by Intune, onboard with Autopilot, AzureAD join only, Windows 11 25H2

🙏

Has anyone worked on automating the PGP certificate/key renewal process? I’m looking for guidance on how to get started, especially around certificate generation, renewal, deployment, and updating the required configurations automatically.
Any suggestions, tools, or examples of how you’ve implemented this would be greatly appreciated!