[Feature] RFC6712 Certificate Management Protocol (CMP) Proxy support for cert-manager webhook.

[Cellebyte]

Is your feature request related to a problem? Please describe.

• RFC6712 Certificate Management Protocol (CMP) Proxy in cert-manager.

If you have an internal CA which is not allowed to create a SubIssuer Cert for the CA IssuerType of cert-manager. You need a simple way of proxying those requests through cert-manager to the external CA. Most of them inside of companies support CMP over HTTPS with different options of CSRs.

Describe the solution you'd like
Hints if this is possible with the current cert-manager or it needs to be implemented.

Describe alternatives you've considered
Implementation as an external Issuer. Then I need support for the development of such an adapter.
Is their any preferred library available or do you know a project which already supports this.

Additional context
Many big companies have internal CA's for their Server Infrastructure and don't want to rely on external CA's for privacy issues They also have a PKI. Most of them support CMP over HTTPs or SCEP if its a Microsoft CA.

Environment details (if applicable):

• Kubernetes latest stable
• Local Deployment
• cert-manager latest
• helm

/kind feature

[vukg]

+1

[munnerz]

Describe alternatives you've considered
Implementation as an external Issuer. Then I need support for the development of such an adapter.
Is their any preferred library available or do you know a project which already supports this.

This is the preferred way - if you can implement a controller as per the design document here: https://github.com/jetstack/cert-manager/blob/master/design/20190708.certificate-request-crd.md you should be able to 'plug in' to the rest of the cert-manager ecosystem neatly (i.e. utilising Certificate resources to get auto-renewal, and annotating Ingress resources to get 'automatic TLS').

You can see an example of one of these, built with kubebuilder here: smallstep/step-issuer#3.

Note that I have linked to a pull request, as they are in the process of a few updates in order to support the latest cert-manager releases - this issuer was implemented at a point where our 'CertificateRequest' doc was not finalised, and there's been some nasty but necessary breaking changes since then. We don't intend to make any more breaking changes here however, so you should be good to begin building against the v1alpha2 CertificateResource resource type (like in that PR!).

[munnerz]

This isn't something that we're going to be staffing ourselves at this point, so would be a good candidate for someone in the community to look into 😄

/priority backlog
/help

[jetstack-bot]

@munnerz:
This request has been marked as needing help from a contributor.

Please ensure the request meets the requirements listed here.

If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-help command.

In response to this:

This isn't something that we're going to be staffing ourselves at this point, so would be a good candidate for someone in the community to look into 😄

/priority backlog
/help

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[munnerz]

Also, whilst we talk about 'external' issuers here, it's worth noting that we are not against/adverse to the idea of an issuer that is developed externally moving into the project, albeit as a potentially optional component.

We've not yet worked out the best UX for 'external issuer management' within cert-manager, nor have we worked out what we want to do in this area, so for now it involves users installing the additional controllers/component themselves.

I can see this being a useful extension, so it may be a good candidate for us to explore how we could move it into the wider cert-manager project over time and what requirements there are to make installation as easy as possible for end users 😄

[jetstack-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to jetstack.
/lifecycle stale

[jetstack-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
Send feedback to jetstack.
/lifecycle rotten
/remove-lifecycle stale

[jetstack-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Send feedback to jetstack.
/close

[jetstack-bot]

@jetstack-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Send feedback to jetstack.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[ralienpp]

I am considering the possibility of working on this, and I'd like to clarify some details.

Having implemented CMP (and other PKI-related tools) in the past, I have a good understanding of the protocol. However, I am not familiar with cert-manager, or k8s. Thus, unless I master the prerequisites, I cannot leverage my CMP knowledge.

@munnerz, would you be available to work in tandem, and break the problem down into parts? For me, the path of minimum resistance would be to write the logic for generating and parsing the PKIMessage data structures that CMP uses, as well as the network i/o (over TCP, and over HTTP, as @Cellebyte requested).

If someone could take over the "glue" for plugging that into cert-manager, the barrier of entry would be low enough for me to make it through.

[sathyanarays]

@ralienpp , I would also like to contribute!

[ralienpp]

@munnerz, does the API of cert-manager have provisions for revoking certificates?

[ralienpp]

This is a status update about the attempt to implement the feature. With @sathyanarays' help I was able to put together a minimal prototyping environment that would invoke the CMP-related logic. However, I was unable to implement a complete solution in the time I had allocated for this, because of struggles with the ASN1 library of Golang.

I describe the challenges I've encountered, perhaps someone can provide assistance, or keep this in mind when attempting it again in the future.

Go's ASN1 library is limited in its capabilities. When reasoning about this in the beginning, I wrongly assumed that if it is in the standard library - it must be a comprehensive implementation. However, that is not the case, in my opinion the documentation has many gaps. It might be enough for an experienced Go programmer, but if you're new to this scene - the few examples are not easy to follow and much is left as an exercise for the reader. One has to look for snippets in other open source projects to get ideas about how a given ASN1 feature can be expressed in Go's encoding/asn1 notation.

So, I failed to implement even a simple CMP request; the protocol has a lot of functionality - implementing it entirely would not be feasible unless someone who knows the ins and outs of asn1 in Go can assist.

Therefore I was thinking of a plan B - wrapping an existing client in a way that makes it usable from Go. For example, there is a full-featured CMP client in OpenSSL, which can be invoked by calling the openssl executable with specific command line arguments. There is also a C library that exposes a CMP API. In other words, the idea is not to re-implement CMP, but to leverage an existing implementation.

I would like to know whether such an approach would be acceptable for being merged into cert-manager. And if not, what would be a good way to decouple this logic into an external plugin, such that others can use it without having to maintain their own fork of cert-manager.

To summarize, my questions are:

1. Would the project be open for accepting an implementation which is not pure Go, but a wrapper around something else?
2. If yes, would (a) starting an OpenSSL process per request be accepted? What about (b) wrapping a C library?
3. If no, can this functionality be refactored into a separate plugin? It would not be a part of cert-manager per se, but could be installed separately by users who need it, without having to maintain their own fork of cert-manager.

For example, I feel rather skeptical about the idea of claiming CMP support with an implementation that spawns a new OpenSSL process for each request. However, in some environments this might be an acceptable approach (e.g. if one is more concerned with full support of all the protocol features, and is less concerned with the Go purity of the software).

/remove-lifecycle rotten
/reopen

[RufusJWB]

Did you decide which CMP message types you want to support? Looking into LwCMP RFC I'd say:

• IR
• CR
• KUR
• RR (if cert-manager at all supports the concept of revocations)

This would reduce the complexity drastically.

One could even boil it down to support only P10CR. This wouldn't be according to the RFC but could by sufficient for this task.

[ralienpp]

I attempted to start with P10CR, and subsequently add others. But as described above, I didn't manage to get that far.

[ralienpp]

@munnerz and others, is there any feedback about the possible approaches for implementing CMP support? (e.g. wrap another program, or a C library)