Hacker News: nickf

New comment by nickf in "WebPKI and You"

nickf — Thu, 12 Mar 2026 23:28:09 +0000

While I sort-of see what you're trying to say, if you knew the groups and teams involved - you'd know there was no favouritism and a strong degree of separation between CA and root programs.

The root programs who have their own CAs are also cloud providers, who arguably have a legitimate need for the CA. Or in Apple's case they have their own CA, but don't issue externally. They keep CA and root program separate.

New comment by nickf in "WebPKI and You"

nickf — Thu, 12 Mar 2026 23:25:58 +0000

That's absolutely incorrect. While CABF sets the 'Baseline Requirements' that ultimately go into the WebTrust audit scheme that root programs use to accept roots into their trust stores...browsers can and do set their own rules.

The reduction of TLS cert lifetime to a max of 398 days was an Apple policy.

New comment by nickf in "Robust and efficient quantum-safe HTTPS"

nickf — Sun, 01 Mar 2026 20:48:33 +0000

Your failure to see the problem doesn’t mean it doesn’t exist. 40x the size might not really be an issue for the hypothetical server you’ve suggested - but that isn’t the reality for the world. Many devices do HTTPS and TLS. Not to mention the issue is more with the clients. CT logs would get a lot harder to run (and they’re already not so easy).

New comment by nickf in "Upcoming changes to Let's Encrypt and how they affect XMPP server operators"

nickf — Tue, 10 Feb 2026 15:45:57 +0000

Google dominate the space because they have an active, robust trust-store program that they manage well. Apple the same. Mozilla and Microsoft too (though to a lesser extent).

If any ecosystem - such as XMPP - wishes to, they could start their own root-program, but many simply copy what Chrome or Mozilla do and then are surprised when things change.

New comment by nickf in "Upcoming changes to Let's Encrypt and how they affect XMPP server operators"

nickf — Tue, 10 Feb 2026 12:43:57 +0000

Not really, no. There are a number of reasons for cert lifetimes being made shorter.

New comment by nickf in "Upcoming changes to Let's Encrypt and how they affect XMPP server operators"

nickf — Mon, 09 Feb 2026 23:14:05 +0000

A public CA checks it one-time, when it's being issued. Most/all mTLS use-cases don't do any checking of the client cert in any capacity. Worse still, some APIs (mainly for finance companies) require things like OV and EV, but of course they couldn't check the Subject DN if they wanted to.

If it's for auth, issue it yourself and don't rely on a third-party like a public CA.

New comment by nickf in "Upcoming changes to Let's Encrypt and how they affect XMPP server operators"

nickf — Mon, 09 Feb 2026 22:54:51 +0000

Eh, it's pretty easy to impersonate if the values in the certificate aren't checked, and you could get one from any of a list of public CAs.

If you're relying on a certificate for authentication - issue it yourself.

New comment by nickf in "Upcoming changes to Let's Encrypt and how they affect XMPP server operators"

nickf — Mon, 09 Feb 2026 22:45:46 +0000

Publicly-trusted client authentication does nothing. It's not a thing that should exist, or is needed.

New comment by nickf in "Upcoming changes to Let's Encrypt and how they affect XMPP server operators"

nickf — Mon, 09 Feb 2026 22:44:38 +0000

Client authentication with publicly-trusted (i.e. chaining to roots in one of the major 4 or 5 trust-store programs) is bad. It doesn't actually authenticate anything at all, and never has.

No-one that uses it is authenticating anything more than the other party has an internet connection and the ability, perhaps, to read. No part of the Subject DN or SAN is checked. It's just that it's 'easy' to rely on an existing trust-store rather than implement something secure using private PKI.

Some providers who 'require' public TLS certs for mTLS even specify specific products and CAs (OV, EV from specific CAs) not realising that both the CAs and the roots are going to rotate more frequently in future.

New comment by nickf in "Upcoming changes to Let's Encrypt and how they affect XMPP server operators"

nickf — Mon, 09 Feb 2026 22:40:57 +0000

You are correct, and the answer is - no-one using publicly-trusted TLS certs for client authentication is actually doing any authentication. At best, they're verifying the other party has an internet connection and perhaps the ability to read.

It was only ever used because other options are harder to implement.

New comment by nickf in "6-Day and IP Address Certificates Are Generally Available"

nickf — Sat, 17 Jan 2026 22:28:26 +0000

It’ll be 5 years soon.

New comment by nickf in "Mozilla's New CEO Confirms Firefox Will Become an "AI Browser""

nickf — Fri, 19 Dec 2025 09:32:45 +0000

I was mostly just typing out what they had listed under 'products' on their pages. I'm aware of what Mozilla do, know folks there and that have been there. They've been roundly criticised for adding 'products' of questionable value to their core userbase, rightly so in my opinion.

New comment by nickf in "Mozilla's New CEO Confirms Firefox Will Become an "AI Browser""

nickf — Thu, 18 Dec 2025 08:04:33 +0000

...which is arguably the problem. Firefox. Thunderbird. That should be it. According to their own site, beyond that they have the browser app for mobile devices. A VPN service, an email-forwarding service, and MDN. Hardly 'many products'.

New comment by nickf in "Upcoming Changes to Let's Encrypt Certificates"

nickf — Tue, 16 Dec 2025 16:46:57 +0000

There are ways to do this as pointed out below - CNAME all your domains to one target domain and make the changes there. There’s also a new DCV method that only needs a single, static record. Expect CA support widely in the coming weeks and months. That might help?

New comment by nickf in "Upcoming Changes to Let's Encrypt Certificates"

nickf — Tue, 16 Dec 2025 11:35:14 +0000

It might never 'touch' the internet, but the certificates can be easily automated. They don't have to be reachable on the internet, they don't have to have access to modify DNS - but if you want any machine in the world to trust it by default, then yes - there'll need to be some effort to get a certificate there (which is an attestation that you control that FQDN at a point-in-time).

New comment by nickf in "Upcoming Changes to Let's Encrypt Certificates"

nickf — Tue, 16 Dec 2025 08:56:31 +0000

Not quite true - some CAs were not 'held hostage' - some agree with the changes and supported them. See the endorsers for SC-081.

New comment by nickf in "Upcoming Changes to Let's Encrypt Certificates"

nickf — Tue, 16 Dec 2025 08:50:11 +0000

Honestly don't recall discussing 17 days, but I could be wrong. 47 days was a 'compromise' in that it's a step-down over a few years rather than a single big-bang event dropping from 397->90/47/less.

New comment by nickf in "Upcoming Changes to Let's Encrypt Certificates"

nickf — Tue, 16 Dec 2025 08:48:41 +0000

Can I ask - if you're using publicly-trusted TLS server certificates for client authentication...what are you actually authenticating? Just that someone has a certificate that can be chained back to a trust-anchor in a common trust-store? (ie your authentication is that they have an internet connection and perhaps the ability to read).

New comment by nickf in "Upcoming Changes to Let's Encrypt Certificates"

nickf — Tue, 16 Dec 2025 08:38:23 +0000

Sure, but in those examples - automation and short-lifetime certs are totally possible.

New comment by nickf in "Upcoming Changes to Let's Encrypt Certificates"

nickf — Mon, 15 Dec 2025 22:54:36 +0000

Chrome root policy, and likely other root policies are moving toward 5-years rotation of the roots, and annual rotation of issuing CAs. Cross-signing works fine for root rotation in most cases, unless you use IIS, then it becomes a fun problem.