Clint,
I'll have to defer to others in terms of available documentation on the
product.
But the certs & keys created are definitely the result of explicit CA
personnel actions - the first action being the establishment of a new
self-signed Root CA. Personnel authentication certificates also must
Tim -
These are not TLS certificates so they cannot easily adhere to the TLS
serverAuth profile. They do not contain the serverAuth EKU
They are currently allowed in the BRs under
6.1.7
#3 Certificates for infrastructure purposes (administrative role
certificates, internal CA operational device
Hi Wendy,
Thanks for this additional information and context. Is there publicly available
documentation for the product and this functionality? I think that might be the
most efficient way to answer some of the questions arising around this. If not,
I have a few follow-on questions. In what
Do these automatically issued certificates have the serverAuth EKU, and is it
necessary for them to chain to a publicly-trusted root? If not, they’re out of
scope for the server certificate baseline requirements. If so, why can they
not be in full compliance with the standard TLS profiles?
Corey -
For at least 1 CA product that I am aware of, issuance of these
certificates is automatic, and we don't believe that issuance can be
disabled, or that a separate private PKI can be used to issue these
certificates instead. In the event a separate, private PKI is used for CA
