Some people are still using the browser tag and applying workarounds as browsers remove support for it (viz. https://certassist.mit.edu/)

Looking at the certassist website, it claims to generate PKCS12, not SPKAC, so I don't think the comment is relevant here.

I believe it generates both. It generates an SPKAC to talk to a issuer server endpoint, which expects the old keygen tag, to get a certificate. That certificate is wrapped, with the key, in a PKCS#12 blob for OS file handlers to import.

(It's also not using OpenSSL, though I've no idea what the server it talks to does.)

(CertAssist author here.) @davidben is correct. Additionally, CertAssist has an advanced mode where you paste in the output from the openssl spkac command, for those who want to use CertAssist with a hardware PKCS#11 provider, or who just don’t want to entrust their private key to a webpage. So there are still use cases for this.

I unfortunately have no visibility into the code of the server that CertAssist proxies its SPKAC requests to, but I can try to inquire with my contact at MIT IS&T. My impression is that ~zero developer resources are available to improve it in any way.

If its still being used (as seems to be the case) it seems premature to remove it.

-1

The OMC can do what it wants, but so far we have one use-case at MIT that has no resources to do any work. That means they don't upgrade to the next release of openssl either, right? Or is certassist used in other places?

So @mattcaswell, the one use-case is abandonware at MIT. Are you keeping your -1/hold?

This goes against the stated compatibility plans so I'm closing this. If someone wants to recreate for a future release, feel free to adopt the branch. :)