How do you deploy CAA records to actually constrain who can issue for your domain?

CAA (Certification Authority Authorization, RFC 8659) is a DNS record telling CAs which of them may issue certificates for your domain. CAs are required to check it at issuance. Deployment checklist.

— Inventory every CA you legitimately use today, including those behind a CDN or a cloud load balancer that auto-provisions certs. Omitting one breaks its renewals.
— Publish issue tags for each allowed CA and a separate issuewild if you restrict wildcard issuance specifically.
— Add an iodef tag with a mailto or URL so a CA can report a blocked, possibly unauthorized, issuance attempt to you.
— Understand the tree-climbing rule: CAs check the most specific name, then ascend to the parent domain. A record at the apex covers subdomains unless overridden lower.
— Verify with dig CAA example.com +short and confirm DNSSEC where possible, since CAA's value rests on the resolver trusting the answer.

Evidence vs. speculation: CAA constrains issuance, not use; it cannot revoke a cert already issued before the record existed.

Further reading: RFC 8659 and RFC 8657 (account and validation-method binding).

Bottom line: enumerate all current issuers first; a forgotten CA turns CAA into a self-inflicted outage.

What is the correct sequence when you must revoke a certificate after a key compromise?

Revocation marks a certificate invalid before its expiry, surfaced through CRL (Certificate Revocation List, RFC 5280) and OCSP. Because client-side revocation checking is famously unreliable, revocation alone is insufficient. Incident runbook.

— Revoke immediately through your CA with the correct reason code (keyCompromise), which CAs and CT monitors treat more seriously than 'unspecified'.
— Do not stop there: rotate to a fresh key pair and reissue, then deploy the new cert, because many clients soft-fail revocation checks and will keep trusting the old leaf.
— If you stapled OCSP, push the new cert so stapled status flips to 'revoked' for clients that do honor it.
— Treat the 24-hour CA/Browser Forum revocation deadline for key compromise as a hard clock, not a target.
— Audit CT logs to confirm no further certs exist for the compromised key, and tighten CAA to prevent reissuance through unexpected CAs.

Evidence vs. speculation: revocation propagation is best-effort; key rotation is the only step fully under your control.

Further reading: RFC 5280 section 5; CA/Browser Forum Baseline Requirements section 4.9.

Bottom line: revoke for compliance, but rotate the key as if revocation will not reach the attacker's client.

ЕЮ Иванов продолжает кошмарить АффПапу, конторку, которая накинула говна на вентилятор этим летом. Тогда в AffPapa не знали, с каким говном идут бодаться, поэтому заслуженно проиграли. 😏

На этот раз ЕЮ зарегал товарный знак AffPapa — совсем скоро имя компании будет официально принадлежать ему. Чтобы убедиться в трушности мува, переходим по ссыл-Очке и вводим серийный номер: 2026793242. Там видим, что заявка на регистрацию подана лично Евгением Юрьичем.

Всё это выглядит забавно, но давайте не забывать, в какой сфере мы работаем и что реально может произойти с жирным троллем за воровство нейминга. Впрочем, толстому не привыкать отхватывать пиздов за проделки в интернете, поэтому ждем очередную фотку разбитого ебала и длинный пост с извинениями. 😏😏😏

В арбитраже денег нет 💵

How do you stand up mutual TLS so the server actually enforces client certificates per route?

mTLS (mutual TLS) extends the handshake with a client Certificate and CertificateVerify, proving the client holds a key trusted by your CA. The trap is configuring it globally when you need it per path. Setup playbook.

— Build a dedicated client-auth CA distinct from your server cert's CA; reusing a public CA would trust every cert it ever issued.
— In nginx, set ssl_client_certificate to that CA bundle and ssl_verify_client optional; at the server level, then enforce per-location with if ($ssl_client_verify != SUCCESS) { return 403; } only where required.
— Set ssl_verify_depth to match your intermediate count; too shallow rejects valid chains.
— Plan revocation for client certs: provide a CRL via ssl_crl or an OCSP check, since a compromised client key is your most likely incident.
— Test with curl --cert client.pem --key client.key against both protected and public routes to confirm scoping.

Evidence vs. speculation: optional plus per-location enforcement is verifiable behavior; 'on' at server scope silently blocks public paths.

Further reading: RFC 8446 section 4.4.2 (CertificateVerify); RFC 5280 for path depth.

Bottom line: scope client-cert enforcement to routes and plan revocation before you trust the first client.

How do you set up Certificate Transparency monitoring that catches a rogue cert within hours?

Because every publicly-trusted cert is logged (RFC 9162), CT turns the logs into a detection system for unauthorized issuance against your domains. A monitor you configure once is cheaper than discovering a mis-issued cert from an outage. Setup checklist.

— Enumerate the full set of names to watch: apex, every subdomain pattern, internationalized variants, and look-alike domains you own.
— Subscribe to a CT monitor (crt.sh RSS, Cert Spotter, or your own poller against the log Get-Entries endpoint) keyed on those names.
— Baseline the current legitimate certs so the monitor alerts on net-new issuance, not on your own renewals.
— Cross-reference each alert against your issuance records: a cert from a CA you never use, or for a hostname you never requested, is the signal.
— Account for the Maximum Merge Delay (typically 24h): a cert may exist before it appears in logs, so CT is near-real-time, not instant.

Evidence vs. speculation: CT proves a cert was issued, not that it is being used; pair alerts with DNS and traffic checks.

Further reading: RFC 9162 section 5 (log client messages); Cert Spotter and crt.sh documentation.

Bottom line: a name inventory plus a baseline turns CT logs from public record into an active alarm.