Multiple Certificate Enrollment Templates for mscertsrv?

[ggilliom]

Hello,

We're looking to implement acme2certifier on a custom server to resolve compatibility issues between ACME clients on our internal servers and our internal Microsoft CA server. In our environment, many different enrollment templates have been used for certificate creation/will be necessary for certificate renewal moving forward.

I've attached an example config for acme_srv.cfg using the mscertsrv_ca_handler.py CA handler. Is it possible OOTB to specify many different certificate enrollment templates? If not, would we need to modify the mscertsrv_ca_handler.py CA handler to support this, or should we take another approach (e.g., running many different instances of acme2certifier alongside each other)?

Thank you!

[DEFAULT]
debug: True
proxy_server_list: {"<domain>": "<proxy>"}

[Nonce]
# disable nonce check. THIS IS A SEVERE SECURITY ISSUE! Please do only for testing/debugging purposes
nonce_check_disable: False

[CAhandler]
# CA specific options
handler_file: <mscertsrv_ca_handler.py file path>
host: <Microsoft CA host address>
user: <username>
# password: <password>
password_variable: <password variable>
ca_bundle: <ca_bundle path>
auth_method: <auth method>
template: <cert template> # how to specify multiple possible templates?

[DBhandler]
#dbfile: /var/lib/acme/db.sqlite3

[Certificate]
revocation_reason_check_disable: False

[Challenge]
# when true disable challenge validation. Challenge will be set to 'valid' without further checking
# THIS IS A SEVERE SECURITY ISSUE! Please do only for testing/debugging purposes
challenge_validation_disable: False

[Order]
tnauthlist_support: False

[grindsa]

if you dont mind to let the client specify the template to be used we could re-use the header_info_field feature. There are some other handlers already using the features and the adaption should not be difficult.

[ggilliom]

Wow, thank you for your quick response! We're planning on using certbot, win-acme, or another similar ACME client, but have not set those up just yet. We will look into providing the client type per request and provide updates. Thank you again!

[grindsa]

If you did not decide on the client I suggest to use either lego or acme.sh Both clients do support modifying the user-agent string which does allow to use the above-mentioned feature...

/G

[ggilliom]

okay great, thank you for the advice!

[grindsa]

Just to keep you updated. Starting from v0.34 we are introducing a profiling feature which allows the definiten of individual enrollment parameters per acme-user. The mscertsrv handler does not support this feature yet. However, modification is not that complex and can be done easily in case you want to make use out of this feature.

[ggilliom]

Hey! Thanks for reaching out about this!Good news: we got certbot working with a2c recently using the msvcce (I think that’s what it’s called) over mscertsrv. I will be sure to pass this information on as I see it being quite helpful.The final issue we needed to resolve was to ensure that certbot used an RSA key instead of ECDSA, at least with the template we were requiring. On the a2c side, the error message was about the key being too short rather than suggesting anything about its actual type. Would it be possible to check the key type if this error is encountered and display it? If so, I’d love to make a contribution as I’m trying to get more into open-source; would love your feedback on this and whether it would make sense as a change.Thanks again for your help!Best,Garrett Gilliom (he/him)On Apr 21, 2024, at 11:41 PM, grindsa ***@***.***> wrote: Just to keep you updated. Starting from v0.34 we are introducing a profiling feature which allows the definiten of individual enrollment parameters per acme-user. The mscertsrv handler does not support this feature yet. However, modification is not that complex and can be done easily in case you want to make use out of this feature. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>

[grindsa]

Hi, contributions are always welcome. So feel free to give it a try,