Open amaccuish opened 6 years ago
Yes currently the only trusted information from the CSR is the public key and common name. If common name is FQDN it is assumed to be server certificate so server, client, and IKE intermediate EKU-s are added, otherwise only client EKU is added.
This is pretty much input sanitization technique here, because it's assumed that you can get all sorts of garbage submitted over the network which might contain malicious bits. I've seen many CA-s doing the same.
Can you elaborate what attributes you're talking about, what is their role in the PKI ecosystem and what usecase you're trying to resolve with Certidude.
So I thought about it being a problem of sanitisation, but you could allow the admin to create and sign such requests.
For smartcards, the DC must have it's GUID stored in the certificate, as a special SAN; the client certificate must contain the user UPN, again using a special SAN. Also the client cert has to have extensions like "scardlogin".
Can you provide a copy of such certificate?
I don't have one that is sanitised for publication, but here are microsoft's words:
DC: https://support.microsoft.com/en-us/help/291010/requirements-for-domain-controller-certificates-from-a-third-party-ca (there's an example cert here)
Supposedly the requirements aren't so strict for Vista+ but I've never gotten certificates to be recognised in Windows for smart card logins without having all the attributes in these docs.
So for testing basically I could use Yubikey, generate CSR on it, submit to Certidude, add some machinery to add relevant extensions, sign CSR in Certidude, write certificate back to Yubikey, configure Windows box for SmartCard login and attempt to log in with Yubikey to the Windows box?
I can do testing if it helps. Or you can just run the resulting certificate through openssl and make sure it has the right stuff in it. I assume this could just be another certificate profile? One for domain controllers (kerberos and ldaps) and one for smart card users?
When uploading a CSR, all custom extensions are removed.
There should be a feature that if the adminstrator approves, the extensions are included in the certificate. For example, this software can't currently be used to issue certificates for smart cards for windows logon, as they require special attributes to be set (certidude removes them on issuance).
Even if these weren't exposed in the GUI, it would be great if this was an option for advanced users (e.g. adding multiple SANs).