cloudflareAug 13, 2026

Certificate Transparency Monitoring is now generally available (opens in new tab)

Certificate Transparency Monitoring helps detect unexpected TLS certificates issued for a domain, but Cloudflare’s own frequent renewals created overwhelming noise. Cloudflare now filters certificates it issued or manages by matching their public-key fingerprints, so customers receive alerts primarily for certificates issued outside Cloudflare. The improved system is now generally available. ## The Problem with Certificate Transparency Alerts - CT monitoring alerts when a certificate for a customer’s hostname appears in a public CT log. - Cloudflare routinely issues certificates through: - Universal SSL - Advanced Certificate Manager - Total TLS - Backup Certificates - Short certificate lifetimes and automatic renewals generated repeated alerts—potentially up to six renewals per year for one certificate. - As certificate lifetimes move toward 47 days by 2029, this noise would increase further. - Customers reported disabling monitoring because routine renewals made meaningful alerts easy to overlook. ## Why Filtering Was Difficult - Certificate management and CT alerting operate as separate systems. - The ordering system knows which certificates Cloudflare creates, while the alerting system only sees public CT log data. - A certificate produces two CT entries: - A pre-certificate - The final certificate - Cloudflare used `stripped_fingerprint` to associate those entries, but the ordering system could not calculate it early enough. - Since the pre-certificate might reach the CT log before the final certificate is recorded internally, lookups could fail and generate duplicate or unnecessary alerts. ## Using the Public Key as the Identifier - Cloudflare needed an identifier that was: - Created before logging begins - Stable from CSR through final certificate - Recomputable from CT data - Unique to each certificate order - The certificate’s public key, contained in `SubjectPublicKeyInfo` (SPKI), satisfies these requirements. - Cloudflare now stores `spki_sha256`, an SHA-256 hash of the DER-encoded SPKI. - The ordering service calculates and records this hash when generating the keypair. - Because Cloudflare creates a fresh keypair for each issuance, matching SPKI values reliably identify Cloudflare-managed certificates. ## How Alert Filtering Works - When the CT alerting service sees a certificate, it recomputes `spki_sha256` from the certificate’s public key. - If the hash exists in the ordering database, the certificate is recognized as Cloudflare-issued and the alert is suppressed. - If no match exists, the certificate is treated as external and an alert is sent. - The same key appears in both the pre-certificate and final certificate, eliminating ordering and timing problems. - Abandoned pre-certificates are also suppressed because they still match a recorded Cloudflare key. - Customer-uploaded certificates continue to generate alerts because Cloudflare did not create their keypairs. Cloudflare’s updated CT Monitoring reduces routine renewal noise while preserving warnings for certificates issued outside its systems, making the feature more useful for detecting genuine certificate mis-issuance.

public-key-cryptographycloudflaretls-certificatescertificate-transparency+3

gitlabFeb 25, 2026

Passkeys now available for passwordless sign-in and 2FA on GitLab (opens in new tab)

GitLab now supports passkeys for passwordless sign-in and phishing-resistant two-factor authentication. Built on WebAuthn and public-key cryptography, passkeys let users authenticate with a fingerprint, face recognition, or device PIN while keeping the private key on their device. Users can register multiple passkeys across browsers, mobile devices, and FIDO2 security keys, improving both security and convenience. ## Passkeys for Sign-In and 2FA - Passkeys can be used: - As a passwordless login method. - As a phishing-resistant 2FA method. - For accounts with 2FA enabled, passkeys automatically become the default 2FA option. - Authentication uses a device fingerprint, facial recognition, or PIN. ## Registration and Compatibility - Users can register passkeys under **Profile settings > Account > Manage authentication**. - Supported platforms include: - Chrome, Firefox, Safari, and Edge. - iOS 16 and later. - Android 9 and later. - FIDO2 hardware security keys. - Multiple passkeys can be registered for access across different devices. ## WebAuthn Security Model - Passkeys rely on WebAuthn and public-key cryptography. - The private key remains securely stored on the user’s device and is never sent to GitLab. - GitLab stores only the public key. - A breach of GitLab’s stored credentials would not give attackers usable private keys for account access. ## GitLab’s Security Goals - Passkeys support GitLab’s commitment under the CISA Secure by Design Pledge. - They help increase MFA adoption while providing a smoother, phishing-resistant authentication experience. - GitLab invites users to provide feedback through its community and feedback channels. Users should register passkeys in their GitLab authentication settings, ideally across multiple trusted devices or security keys for both stronger protection and account recovery.

public-key-cryptographygitlabdevsecopssecurity+4