I'd love to use my own CA, but the 3rd party that needs these certificates wants them issued by a trusted CA; essentially a CA trusted by the browsers by default.
There’s nothing special about a “client certificate” —- they’re not (necessarilly) any different than a TLS server certificate. Technically a relying party might check that a client certificate includes the “client auth” key use, but most (all?) commercial certificates issued for TLS/HTTPS servers do this (I know Let’s Encrypt does).
So... what they’re asking for isn’t actually anything fancy. Just go buy a normal certificate like you would for any other server (or get one for free from let’s encrypt).
In fact, if they want a cert that is signed by a CA that “works in browsers by default” it must be the case that what they’re looking for is a vanilla commercial “Web PKI” certificate. This must be true because the CA/Browser Forum requirements that commercial CAs are audited against stipulate that CAs are only allowed to sign vanilla certificates. They can’t sign anything fancier.
It sounds like what the vendor you talked to was trying to sell you was a commercial CA that they manage for you. In other words, your own root certificate authority. Those certificates would not be trusted by browsers by default. There’s no reason to pay for that — you could just run a CA yourself and do the same thing. In fact I contribute to an open source project[1] that does exactly that, if that’s what you end up needing.
Unfortunately no. That's how I think client certificates are usually given; generated with a self signed CA, but this 3rd party API want's a pre-trusted CA, not a self signed one.
Comments
I'd love to use my own CA, but the 3rd party that needs these certificates wants them issued by a trusted CA; essentially a CA trusted by the browsers by default.
Have you ever run into a similar situation?
There’s nothing special about a “client certificate” —- they’re not (necessarilly) any different than a TLS server certificate. Technically a relying party might check that a client certificate includes the “client auth” key use, but most (all?) commercial certificates issued for TLS/HTTPS servers do this (I know Let’s Encrypt does).
So... what they’re asking for isn’t actually anything fancy. Just go buy a normal certificate like you would for any other server (or get one for free from let’s encrypt).
In fact, if they want a cert that is signed by a CA that “works in browsers by default” it must be the case that what they’re looking for is a vanilla commercial “Web PKI” certificate. This must be true because the CA/Browser Forum requirements that commercial CAs are audited against stipulate that CAs are only allowed to sign vanilla certificates. They can’t sign anything fancier.
It sounds like what the vendor you talked to was trying to sell you was a commercial CA that they manage for you. In other words, your own root certificate authority. Those certificates would not be trusted by browsers by default. There’s no reason to pay for that — you could just run a CA yourself and do the same thing. In fact I contribute to an open source project[1] that does exactly that, if that’s what you end up needing.
[1] https://github.com/smallstep/certificates
Nope, this really is weird. Can't you add a root CA to the machine providing the service? e.g. https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_...
Unfortunately no. That's how I think client certificates are usually given; generated with a self signed CA, but this 3rd party API want's a pre-trusted CA, not a self signed one.
I still can't understand what's going on :(
Who's doing what, and which machine connects to the other one?