sekinfo

An idea to make EV certs somewhat more useful:

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.

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.

Question for HN regarding EV certs:

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.

64 days might seem like an arbitrary number, but it’s a simple cascade:

64 days = 2 maximal month (62 days) + 1 day wiggle room + 1 day because 63 would be even weirder.

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.

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.