Boulder: Managing Certificate Profiles

[standenemy]

Hello!

I was unsure whether to ask questions over at the LetsEncrypt forums or here-

Is there a way to properly manage certificate profiles? Permitting a machine to issue cert profile a, have different extensions applied, etc ..

I would greatly appreciate being pointed in the right direction for this. Thank you in advance.

[cpu]

@standenemy I'm afraid I don't have enough context to understand your question. Are you running Boulder and looking to change/manage the certificate profiles it issues under?

[standenemy]

I am testing Boulder and I am looking to see how far can I play with certificate profiles.

How can I control access to certain certificate profiles(and from which available contexts, like 'user' or requesting server, etc.), how to add supported certificate extensions, how to add Extended Key Usages if missing, how to apply constraints to certificate profile fields or static unmodifiable values to non-extension fields .. and to be honest, how do I even add or remove certificate profiles at all?

Thanks again.

[jsha]

Right now Boulder supports just two certificate profiles, rsaEE and ecdsaEE, configured in test/config/ca.json (or equivalent in config-next). You can edit the profiles there. They use the config format from cloudflare/cfssl. There's no support for selecting profiles based on user or requesting server. You could simulate that by running multiple Boulder stacks with different configured profiles, and restricting access to those stacks.

[standenemy]

While trying to fiddle with that file, I have seen that throughout the code itself, there are variables and methods that only support usage of those two profiles. I am mostly referring to ca.go.

Further reading of the closed issues suggests a secondary profile was created in order to differentiate between RSA and ECDSA. Upon even further reading of using certbot suggests that at runtime, the keytype from the CSR is read and then decided to be used with a specific certificate profile for that extrapolated public key(Not entirely sure about this one).

My problem is this. How do I differentiate between created certificate profiles at runtime of the project with properties other than key-type? For example I want a certificate that is used with EKU x,y,z and for another service I'll want them to be able to create a certificate with only EKU's x,y et cetera.

I only want to see if I understand correctly. This functionality described is not a use case for LetsEncrypt as a whole, and understandably so, due to the mission statement. But for this goal .. it seems the code does not exist yet to support this modularity of profiles. Did I get that right?

I hope I'm not violating any rules by commenting on a closed issue, as this is the same topic and I did not want to double-post.

Thank you very very much in advance.

Edit: Rephrasing of paragraph 3.

[jsha]

for this goal .. it seems the code does not exist yet to support this modularity of profiles. Did I get that right?

That's correct. No worries about commenting on a closed issue; I've temporarily reopened it for discussion.

One relatively simple way to solve this problem with the current code base would be to run two separate Boulder stacks, and configure the client with a different URL depending on which type of certificate they are requesting.

In general, this is an area that has been somewhat under-specified in ACME, mostly because Let's Encrypt has been leading implementation and we've had relatively few needs in terms of varying certificate profiles. If you have input on how things should work, I'm sure we and the ACME WG would welcome it (though we might not want to land code in Boulder if we're not planning to use it). The main options I can see are:

• Different directory URL per profile
• Specifying a list of profiles with descriptions in the directory, and making a profile name part of the new-order request
• Specifying desired extensions in the CSR and getting an error if they don't match an available profile