grindsa

Thank you for fixing. I did test and can confirm that the problem is solved. One other small remark: I see that the certificate has a `CN=testrfc7030.com` but is missing...

The above statement rather refers to CN tan to SAN. I read it in a way that you have to have a SAN but there is no need to set...

BTW: if you are replacing the certificate an you please also sign it with ecdsa-with-sha256 instead of ecdsa-with-sha1. This will stop clients complaining about weak signature digest algorithm. ``` curl...

You proposal makes sense however the implementation is not that straight forward as it also requires modifications on the [certsrv](https://github.com/magnuswatn/certsrv) module. I am planning to look into it as part...

Feature made it into [v0.35](https://github.com/grindsa/acme2certifier/releases/tag/0.35). Thus, closing this issue. In case you have comments feel free to reopen...

Can you describe your deployment (containerized, rpm, deb or manual installation). Can you share your `acme_srv.cfg` as well as the related `krb5.cfg`? Can you please enable debugging in `acme_srv.cfg` replicate...

I see this error from time to time in my lab as well. In the past I thought its related to my setup (i am accessing the MS CA via...

Hi, Sorry for not commenting earlier but i was quite busy the last few weeks. I agree that the error is most likely not related to the acme-client. The reason...

Hi, Sorry, I am still not able to replicate the issue. However, its worth to try if increasing the [timeout of the dce-connection](https://github.com/grindsa/acme2certifier/blob/mscertsrv/examples/ca_handler/ms_wcce/target.py#L120) will help you to overcome the issue....

Closed due to inactivity.... In case you would like to follow up please re-open....