Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: Custom attributes #41

Open
amaccuish opened this issue Feb 23, 2018 · 6 comments
Open

Feature Request: Custom attributes #41

amaccuish opened this issue Feb 23, 2018 · 6 comments

Comments

@amaccuish
Copy link

amaccuish commented Feb 23, 2018

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
Copy link
Owner

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
Copy link
Author

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 laurivosandi added this to the Better HSM integration milestone Feb 25, 2018
@laurivosandi
Copy link
Owner

Can you provide a copy of such certificate?

@amaccuish
Copy link
Author

amaccuish commented 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
Copy link
Owner

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
Copy link
Author

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants