Integration with keepass

[LecrisUT]

I am having an ambition to create some interoperability between step (and if possible other client certificate issuers) and keepass databases. The main goal is to have the keepass client when unlocked check the stored certificate, and if expired go to the CA and get a new one and store it in the database. That way only when you have the master password, would you be able to renew the certificate, and with the low life-time of step-ca certificates it makes a great combo.

As for the implementation, I could use some insight and advice:

• what authentication method can be accessed programmatically. Something like oauth would be great, but if it's possible to user control with jwt maybe that would be easier to implement?
• are there any step libraries that can be accessed externally through c++?
• are there standard interface methods which can be used for other CAs besides step-ca?

[maraino]

what authentication method can be accessed programmatically. Something like oauth would be great, but if it's possible to user control with jwt maybe that would be easier to implement?

step-ca supports the provisioner OIDC and JWK, the JWK uses a JWT signed with the JWK defined in the intermediate, so both of them can be used.

are there any step libraries that can be accessed externally through c++?

All our code is in Go, It might be able to compile the required packages as a C shared library, but I think it's probably better and simpler to use libraries in C++, for example, you will need one to sign JWT, one HTTP client that post to /sign with a given CSR and the signed token, you will need of course to be able to read JSON, and of course generate the CSR and a key, you might be able also to pass this as parameters.

are there standard interface methods that can be used for other CAs besides step-ca?

No, each online CA will have a different way to sign a certificate.

[LecrisUT]

So between JWK and OIDC. I assume that the latter cannot be accessed without the user interaction, at least initially, but is there something that can be retrieved and stored securely on the database to automatically renew? Maybe a cookie or something standard in OIDC protocol?

As for the former, can I prepare it in such a way that it can only be used for one email address for the user certificate. Using step, I simply passed the intermediate CA's password and it worked, but maybe it's not safe to hand that over to whoever wants a client certificate.

For the libraries I should be able to find the appropriate ones thanks to your advice.

[maraino]

The OIDC requires user interaction. We don't have plans to integrate with a full OAuth2 to refresh tokens and get new OIDC tokens. However, a non-expired and non-revoked x509 certificate can be used to renew itself using mTLS using the /renew endpoint (try it with step ca renew test.crt test.key)

First, step ca init uses the same password to encrypt the root, intermediate and JWK keys to simplify the process, you can use --provisioner-password-flag on init to add a new one for the provisioner, or just add a new one with one generated using:

step ca provisioner add --ca-config ca.json --create [email protected]

You can remove the old one with step ca provisioner remove or just generate a new one and manually replace it with:

# Create the keys
step crypto jwk create jwk.pub jwk.priv

# Convert the jwk.priv to the compact form:
cat jwk.priv | step crypto jose format

# Manually edit ca.json, and replace the "key" and "encryptedKey" attributes 
# with the public key  and compact form of the encrypted private key.

That way you don't need to share the password of the intermediate, and by the way, you can also change this one with step crypto change-pass.

I don't think you're asking for this, but it's also possible to restrict the SANs using certificate templates, you can use a template that extracts an email from the token and fail if it does not match what's expected. Another way is to generate an intermediate with email constraints. We don't check those at the signing time, we rely on TLS implementation to actually validate those ones.

[LecrisUT]

The OIDC requires user interaction. We don't have plans to integrate with a full OAuth2 to refresh tokens and get new OIDC tokens. However, a non-expired and non-revoked x509 certificate can be used to renew itself using mTLS using the /renew endpoint (try it with step ca renew test.crt test.key)

That is good to know. In that case I can code a test to renew and if it fails open the browser to re-authenticate.

you can use --provisioner-password-flag on init to add a new one for the provisioner, or just add a new one with one generated using:

Is it made specific for only one CN? Wouldn't creating a new JWK for each user certificate become problematic?

I don't think you're asking for this, but it's also possible to restrict the SANs using certificate templates, you can use a template that extracts an email from the token and fail if it does not match what's expected. Another way is to generate an intermediate with email constraints. We don't check those at the signing time, we rely on TLS implementation to actually validate those ones.

I should implement the SAN/email restriction so it cannot be misused outside my domain, e.g. in SMTP client certificates.

[maraino]

Is it made specific for only one CN? Wouldn't creating a new JWK for each user certificate become problematic?

A JWK provisioner is not specific to any common name, you can sign any certificate with it. The provisioner name, that we suggest in step ca init to be an email can really be anything, it's just a way to identify it.

[LecrisUT]

Well that would leave it open to impersonation. To overcome this, I guess the best implementation is using OIDC and have the user occasionally re-login if they become inactive for too long. Thank you for the advice, I should be able to work around this and make some rudimentary compatibility.

Should I be aware of anything else, current or upcoming? Like would it play well with step ssh?

[maraino]

@LecrisUT I've just learned about this client in rust https://github.com/Bluestone/tinystep, I don't know of which features it supports, but it might be easier to integrate a C++ app with this.

[LecrisUT]

I will try to look in the implementation for some reference. It seems it uses the HTTP interface so there should be C++ equivalent libraries for each.