Multi Client / Multi CA Approach

[irenaeusbecker]

Hi all,

just found your ACME2Certifier based on internet search which looks very nice for my potential project to support multiple CA's etc.

Just an idea to discuss... is it possible to extend your project to support a workflow and order process which orders a certificate in the background at different ca's and potentially will hand over the certificate back to ACME Server? The idea is to support multiple CAs for one customer with one ACME Server.

Best would be also to support multiple customers on one platform by using templates, but this is just a nice to have.

Would be great to start a discussion with you.

[grindsa]

Hi,

the idea is nice but requires significant changes on the a2c architecture. I am not sure if it is worth the effort as i belive that a solution with multiple a2c instances on one host and a proxy like Traefik, Caddy or NGINX in front would do the same job. Customer provision could be done via an external system and then provide eab-credentils to client which can be used for authentication towards the respective a2c instance.

Thoughts?

[irenaeusbecker]

Hi,

i agree to your approach in the front by using proxy etc which can be done with less effort.
Can you please explain a little bit more the handover of requested CA certificates back to acme2certifier so that customer will finally get his requested certificate? EAB Credentials will surely help to have a unique identifier but is there today a potential API to connect such kind of external system?

Thanks in advance!

[grindsa]

Hi,

One idea is to have one a2c instance per CA. All instances are reachable via different endpoints (https://a2c.foo/ca1/acme/directory, https://a2c.foo/ca2/acme/directory). Every instance would have its own set of eab-credentials. In such scenario customers would share instances. By reaching to a certain instance, they would get the right certificate. This is already possible as of today.

Another option would be to support multiple CAs per instances. CA selection could be done based on eab-credentials meaning you have a 1:1 mapping between eab-account and CA. This is not fully according to the standard but well... its also not against the standard. This would come with some code-changes, but the effort should be reasonable.

The eab-credential management in both cases could be done in an external CRM system. a2c would connect to this system by using a customized EAB handler. Identification and authentication of an a2c instance towards the CRM system can be done by configuration parameters to be inserted in acme_srv.cfg.

Hope my explanations make sense. If not let me know...

[grindsa]

Just to keep you updated. Starting from v0.34 we are introducing a profiling feature which allows the definition of individual enrollment parameters per acme-user. So assuming that you use "external account binding" you could define different CAs or enrollment profiles per customer. Input format is described in the a2c documentation; provisioning could be done out of the above-mentioned order-database.