IdentityServer4 integration (C#) mTLS

[joaoantunes]

I'm using IdentityServer4 (C#): is an OpenID Connect and OAuth 2.0 framework for ASP.NET Core.

I will host IdentityServer4 using Kubernetes + SQL Database for storing client information. In order to validate the client and issuing the JWT tokens, we need to register the client information on the Database. This requires to store the ClientId and Client Secret (thumbprint of the Certificate or Certificate Name)

Why is needed

IdentityServer4 is a centralized generic way of securing API communication providing multiple protocols but has no features of issuing certificates, and mTLS requires this.

What is needed

• Produce client certificates and register them on IdentityServer Database (client id + client secret and claims)
• Deliver client certificates to clients running in Kubernetes, using either Kubernetes secrets or volumes.
• Deliver client certificates to external clients (windows users) "On-demand"
• Automate client certificates renewal (will this affect the thumbprint store in the Database? or even the Certificate name?)

Is possible to do the above topics using Autocert? I've been reading about, Autocert, step-certificates, and Cert-manager.
I think the above solutions are possible to achieve with step-certificates right? But step-certificates won't auto-renewal the certificates and won't deliver them to the Kubernetes containers right? How can I achieve this, does Autocert helps on this, I don't think I can use Autocert since I require to register the certificate name/thumbprint on IdentityServer4 Database, is it possible to do it, How?

[maraino]

@joaoantunes

I don't know anything about IdentityServer4, and I don't really understand all the scope of what you're trying to do, but let me try to answer some of your questions.

First autocert uses JWT tokens to get the X.509 certificates (TLS) from step-certificates (aka step-ca), those JWT tokens are generated by autocert using a shared key between autocert and step-ca. It doesn't support OIDC, but ... (to be continued)

Deliver client certificates to clients running in Kubernetes, using either Kubernetes secrets or volumes.

Autocert can create in a k8s pod client/server certificates and renew them using the JWT token.

Deliver client certificates to external clients (windows users) "On-demand"

It those users are persons, I don't think they will be using autocert, they will be using the step cli to get the certificates from step-ca using an OIDC token obtained after the user logs in, usually using a username, password, in a third-party identity provider, or IdP, in your case, I'm assuming that would be IdentityServer4. By default, those certificates are valid for 24h, but this can be configured.

Automate client certificates renewal (will this affect the thumbprint store in the Database? or even the Certificate name?)

Autocert takes care of the renewal of the certificates inside pods, but when you renew a certificate it always changes, the thumbprint will change, but it will still be using the same key, and names.

People certificates can be renewed using step ca renew command or doing the log-in flow again creating a new certificate. It's also possible to run step ca renew as a daemon, so it renews the certificates automatically.

Produce client certificates and register them on IdentityServer Database (client id + client secret and claims)

The OAuth2.0/OIDC flow for users requires a client id + client secret, these values are unique and configured once.

But if you're using OAuth2.0 to authenticate "machines" using a client id+secret this flow is not supported by step.

---

By default, all certificates generated by step-ca can be used for mTLS authentication with other client/servers as long as the root is shared.

---

Now let's continue with the but ... When a pod with an autocert annotation is scheduled, autocert automatically injects a bootstrapper init container that generates the initial certificate using the JWT token generated by autocert. That container basically runs this script https://github.com/smallstep/autocert/blob/master/bootstrapper/bootstrapper.sh

And with some work, you should be able to adapt it to generate the certificate using a different way, but an OIDC flow for users would be hard, but if IdentityServer4 provides a different way for "machines" it can be achieved.

The other component that autocert injects is a sidecar container that just takes care of the renewal it just runs this command https://github.com/smallstep/autocert/blob/master/renewer/Dockerfile#L8

---

I hope I've answered some of your questions.

[dopey]

Hey @joaoantunes let us know if you're still experiencing issues or have more questions. Otherwise, we'll mark the issue closed for the time being.