mirror of
https://github.com/laurivosandi/certidude.git
synced 2026-04-25 00:25:57 +03:00
[GH-ISSUE #41] Feature Request: Custom attributes #31
Labels
No labels
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/certidude-laurivosandi#31
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @amaccuish on GitHub (Feb 23, 2018).
Original GitHub issue: https://github.com/laurivosandi/certidude/issues/41
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).
@laurivosandi commented on GitHub (Feb 25, 2018):
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.
@amaccuish commented on GitHub (Feb 25, 2018):
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".
@laurivosandi commented on GitHub (Feb 25, 2018):
Can you provide a copy of such certificate?
@amaccuish commented on GitHub (Feb 25, 2018):
I don't have one that is sanitised for publication, but here are microsoft's words:
Client: https://support.microsoft.com/en-gb/help/281245/guidelines-for-enabling-smart-card-logon-with-third-party-certificatio
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.
@laurivosandi commented on GitHub (Feb 25, 2018):
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?
@amaccuish commented on GitHub (Feb 25, 2018):
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?