Similar to HSTS Preload List, a domain owner can enroll the domain into an "EV only" program on a yearly basis, such that the list of "EV only" domains will be preloaded into major web browsers. Browsers will refuse to accept any certificate for the domain which is not EV. The browser UI does not need to change.
Would be cool, but IDK how much it'd help. The modern threat model it seems is very much phishing / getting people to enter creds onto sites that they think belong to their bank or whatnot, but are in reality different, unrelated domains. Since the domain is different HSTS, etc don't apply.
Training people to "look for the big green badge and make sure it says JPM Chase, USA" seems easier than "you have to make sure it's chase.com EXACTLY". But in reality the solution is to use a password manager with URL matching (or passkeys... But ehh)
Great work, did a similar analysis recently but only for the top 50, and in fact none of the top 50 had an EV at the time of the survey.
I believe the only possible advantage of an EV is not a technical one, but rather an organizational one: it encourages the use of a unique keypair on each server because Wildcard coverage is not allowed (although multi-domain is allowed). For what appear to be non-technical reasons, I have seen many entities copying their keypairs for Wildcard certs between servers, even between business critical on-prem backends and cheap shared hosting or budget VPS, or handing the keypair over to a contractor via email.
Have seen some entities request a large number of EV certs (more than 10, sometimes up to 40) for subdomains under a single domain. At the same time, they are requesting OV Wildcard certificates for the main domain, which have overlapping coverage with the EV certs. These entities do not have any regulatory requirements to use EV as far as I know.
Is there any point in doing this?
The overlap from the Wildcard would seem to nullify any theoretical advantage of the EV cert, given that both will be recognized as valid certs that can cover the subdomains. This in addition to the fact that browsers do not treat EV, OV and DV certs differently in any significant user-facing way since many years now.
Frequently these entities also use Let's Encrypt DV certs on some subdomains alongside their EV certs, so of course a CAA record cannot be used to limit emissions to the CA which emitted the EVs.
Can anyone think of a legitimate technical motivation to use EV certs alongside an overlapping Wildcard OV and various DVs?
> Basically, instead of doing DLP/URL filtering/risk management on a MITM box, they're pushing it to the browser. This helps remove the need for TLS decryption, and the need to funnel their browser traffic to any particular tunnel endpoint.
This is where it should have been done in the first place instead of breaking TLS and creating enormous risks when that corporate MITM private key goes for a walk.
I think that these DLP/content inspection solutions should not be preferred as a first line or blanket solution because they are inherently risky and can easily be deployed wrong. Not to mention creating big privacy and security risks for users, such as when someone wants to check their bank balance from their work machine.
But in cases where there is a clear benefit when dealing with highly sensitive information, doing this inspection right in the browser is the least worst option from a security perspective when it is correctly integrated with the browser and not hacked on.
Have done small to medium institutional rollouts of Firefox in different orgs, some of which were on top of a Linux base and others a Windows base. Windows deployments include Firefox in the base image and configuration is managed with AD and Ansible. Linux deployments manage configuration with Ansible. The preinstalled browsers were removed or disabled.
All users received an orientation and were informed that Firefox is the only approved browser.
Firefox was pinned to the desktop and taskbar, usually with the name "INTERNET" as the web browser is commonly known here.
The number of support tickets was very small. Usually if a user reported a problem with the web browser, it was a page that was also broken in Chrome or some other network issue.
Users reacted positively when they saw that there are no ads in Firefox. uBlock Origin was preinstalled.
Without ads and tracking scripts the web browser is massively faster, which also was perceived by users.
If there is any initial resistance to Firefox, it usually melts quickly.
The only bother has been the frequent UI updates to Firefox, which occasionally cause frustration until we apply a new configuration to revert whatever fresh horrors Firefox designers have birthed. With ESR, these problems are less frequent.
I hope this Firefox Enterprise freezes the UI to the classic "tabs look like tabs" aesthetic, maintaining the option of vertical tabs.
It's absolutely insane to me that more orgs aren't rolling out things like uBlock Origin. In fact, at my bigbrain sillycunt valley job I am forbidden by policy from installing it (though no technical control in place). It's the simplest, highest ROI protection you can use on the web imo.
I briefly read institutional as 'intentional', with both in mind, the standardization of experience is something that's really wroth thinking about.
One feeling I am starting to get is server side web apps might make more of a re-emergence, because putting so much application and business logic in the front end serves as a bigger footprint for possible security issues.
With respect to resistance to browsers (or preference for something else), I agree that users seek familiarity and those who got to start with Firefox do still remember it.
Mozilla is just one org, but it's relative independence will hopefully provide other perspectives to using a web browser as a universal interface, not just for humans, but our new sentence-dna containing friends.
If you want to update your ACME configuration to use these new 64-day certs now to get a head start on the transition... there's currently no way to do so.
LE for reasons unknown did not opt to use their "profile" capability to allow subscribers to select 64 day certs as an option. They mention that they will update their staging environment on 2026-10-14 to use 64 day lifetimes, presumably with the "classsic" profile although they do not specify. But the staging env is not useful if you need a valid browser-trusted cert.
Agreed, there is a problem with how certs are managed in large organizations.
Many believe a Wildcard cert is a license to copy the same private key and cert everywhere. They have no problem
copying their single private key to budget VPS services or foreign providers
who are known CLOUD and collection program participants, the same private key
used for "high security" on premise servers.
Also amusing to see some organizations using ACME cert tools manually on each
and every server in fleets of 10 to 100, every 80 days or so, when they remember to do so. Outages
tend to be pretty frequent due to missed renewals.
The only solution is automation, whether with an off the shelf ACME client with
a cron job or a more complete automation platform. Let's Encrypt is not the
only CA that supports automation, there are quite a few that support ACME or
other nonstandard APIs. There is almost no setup that cannot be fully
automated: legacy web servers, hardware load balancers, cloud load balancers,
etc.
It is also absolutely possible to automate OV and EV renovation if an
organization insists on these "fancy" certs, which are frankly irrelevant to
security because browsers do not treat them differently in any significant way.
You can't pin a domain to only OV or EV type certs, which would be useful. The
documents used for validation need to be updated periodically (data reuse
times are going down too), but the rest of the process can be fully automated.
I do not see any reason not to automate cert renewal given the changes in
lifetimes, although I feel for the hobby server operators who have to deal with
more complexity. For hobby use cases, just set up an ACME client with a cron
job and be done with it.
I don't agree that this is a positive development if a resilient worldwide PKI
is desired.
1. We have seen how Cloudflare can "break the Internet" due to their position
as a SPoF. Let's Encrypt also became a SPoF as their popularity grew.
2. Cloudflare's main service depends on breaking the trust model of TLS, which
is to say that users must be assured that they can communicate with a server
without the possibility that third parties are observing or tampering with the
connection. If I direct my user agent to example.com, I expect that my TLS
connection is terminated by the operators of example.com, and any contents sent
and received are between me and the servers associated with example.com.
Cloudflare breaks that assumption by performing TLS interception between my
user agent and the server. Yes it is true that other services, such as cloud
load balancers, do the same thing, but we should not accept that this creates
an important opportunity for interception or tampering due to commercial
interest, duress etc.
3. Furthermore Cloudflare allows operators to present a TLS certificate to
clients even when the origin server does not use TLS, leading them to believe
that their connection is secure even when the leg between Cloudflare and the
server is not encrypted: the so-called TLS façade.
4. Cloudflare is incorporated in a jurisdiction that has been seen to behave in
a hostile, or at a minimum highly arbitrary, fashion, and has been involved in
pressuring infrastructure operators to do their geopolitical bidding and
personal favors to the executive. Of course Let's Encrypt also has this
weakness.
Are we to believe it is a good thing that a known SPoF becomes an even more
critical SPoF? That an actor who subverts TLS becomes a CA? More concentration
of infrastructure control in a single jurisdiction that does not respect
international norms?
Cloudflare promoters will say that points 2 and 3 are always the choice of the
server operator. However Cloudflare takes advantage of the fact that most
server administrators actually understand very little about how TLS, or even
the Internet, works. I frequently observe that the operators of critical public
services on the Internet fundamentally misunderstand basic technologies such as
DNS, IP, TLS and HTTP. For those people, Cloudflare gives them an easy option
to "stop the DDoS", without understanding the implications of sending their
traffic to a foreign actor who will perform TLS interception. And in many
cases, using Cloudflare turns into a ritualistic mimicry that is performed as a
preventative rite to placate the DDoS spirits.
It is also concerning to me the suggestion that CAs which are not GTS, CF and
LE are somehow considered "legacy CAs" now. In what sense?
LE recently updated their policies to say explicitly that they will comply with
export restrictions:
Let me remind you that the implied "modern" CAs mentioned must also comply
with export restrictions, but furthermore they are subject to non-public
pressure dynamics from the executive which may result in arbitrary service
terminations at the individual, organization or country levels. This as well as
compliance requirements with CLOUD and collection programs.
I propose that the goal should be to look for a way in which we can have
widespread availability of free DV certificates for everyone who needs one,
independent of their nationality, from multiple geographically distributed
providers in diverse jurisdictions, coupled with a sustainable economic model
for CAs which are not operated by the tech behemoths.
There are actually non-behemoth CAs, besides LE, which already provide free DV
certs, ACME compatible, for example:
SOAP API in 2026 - this seems fine? Fundamentally we are talking about
exchanging XML documents over a request/response protocol, generally HTTP,
which is a still pretty well supported thing to do even in 2026.
The actual XML formats contained in the messages can be anything that can be
represented with an XML schema. Obviously some schemas are better designed than
others, but having a standard way to represent complex business documents with
well-defined composable components, nesting, and having sufficient flexibility
to handle defined variations of those documents is generally a good thing.
If you compare a good XML-based API implementation with the disaster that is
the v1/chat/completions JSON API, which is a monster to correctly deserialize
into typed structs, you will understand why XML protocols can still be a good
choice. The typical ad hoc JSON API has the advantage of being the lowest common
denominator, and does not require the designer to think much about their schema
before rushing to publish their API. JSON gives you lots of opportunities to
make design mistakes whose costs will largely be supported by consumers of the
API.
The SOAP spec itself is abandoned since 2007, but being built on other
protocols such as XML, HTTP, TLS, TCP means it has benefited from the advances
there. I don't see anything that is inherently outdated in the spec.
From my perspective, one of the biggest weaknesses is regarding the typical
authentication mechanism with SOAP, but the spec itself does not prescribe any
particular auth implementation. You can and should ignore WS-Security and
choose a simple bearer token or better yet mTLS if you want to avoid text-based
credentials being passed all over the place, often without any sane way to
revoke or rotate them.
I see some comments about WSDL and Go: hooklift/gowsdl worked fine for us. We
built a certificate automation platform in Go which interfaces with multiple
CAs through their APIs, and one of them handed us a WSDL file for their SOAP
API.
Other than some quirks with how the API handles namespaces and attributes which
I believe are due to a misconfigured XML parser on the backend, hooklift/gowsdl
worked great. The generated structs and functions worked fine after massaging
some of the serialization annotations to deal with the quirks.
This CA later told us they were going to replace their quirky but perfectly
functional SOAP API with a "REST API", which given that the cert issuance process
requires state, doesn't seem consistent as REST is a stateless protocol. I
think there is a tendency to call any JSON API a "REST API" to lend it
credence. My response was that they would be better served correctly
configuring their XML parser to handle namespaces as per their own WSDL
definitions so that using the WSDL to generate the code works without a bunch
of tweaks. I would much rather use a well-designed SOAP API than an ad hoc JSON
API strung together with liberal amounts of vibe coding, which is the current
trend.
This CA also had a unique authentication mechanism by requiring the credentials
to be placed in the body of each and every XML document sent to the API, in
plain text. So anything or anyone that needs to process, log or debug any XML
document also gets a copy of the credentials. Also the same password used to
log in to the web interface. Don't do that.
EV Preload List
Similar to HSTS Preload List, a domain owner can enroll the domain into an "EV only" program on a yearly basis, such that the list of "EV only" domains will be preloaded into major web browsers. Browsers will refuse to accept any certificate for the domain which is not EV. The browser UI does not need to change.
reply