-
Notifications
You must be signed in to change notification settings - Fork 33
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
acme.sh fails with "Sign error, wrong status" when a2c ca_server.get_cert() fails with error: The NETBIOS connection with the remote host timed out. #154
Comments
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 ssh tunnel) but it does not seem to be the case. I will look into it during the upcoming days however are you saying that the same setup works fine with other acme clients? Is it a permanent issue when using acme-sh? |
I normally test with acme.sh so I've seen this error mostly when using acme.sh. however, there was one instance where it also happened with cert-manager. |
the error appears more and more now, from both cert-manager and acme.sh. any idea yet? |
It's unlikely that the choice of ACME client would affect a server side NETBIOS connection. The error in question is being thrown by the impacket library: https://github.com/fortra/impacket/blob/master/impacket/nmb.py#L285 however the wording is their default for that exception type and the point where it occurs will vary. Beware cached name resolution if your target machines IP address will change. |
@webprofusion-chrisc I agree, I was just answering the previous question if the error occurs from different clients. I'm not sure if the cached name resolution is the issue here. the target machines (both DC and ADCS CA) have static IP addresses. Also it's worth noting:
I was thinking to have a temporary workaround to read the error in the exception at acme2certifier/examples/ca_handler/mswcce_ca_handler.py Lines 241 to 243 in bc9deb6
cert_raw = convert_byte_to_string(request.get_cert(convert_string_to_byte(csr))) again before failing.
|
the workaround didn't work after all. I tried to catch the error, sleep for 2 seconds then try building the request again |
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 for asking is that I am looking for a reliable way to replicate the issue. Let me give it another try over the weekend. /G. |
Hi, Sorry, I am still not able to replicate the issue. However, its worth to try if increasing the timeout of the dce-connection will help you to overcome the issue. Default is 5 seconds, maybe a higher value works better in your environment. I updated the handler and introduced an [CAhandler]
...
timeout: 20 Please give it a try with the updated handler) and check if things get better. |
When using acme.sh with a2c and mswcce_ca_handler.py, there's a strange behavior that happens.
All VMs (a2c, acme.sh, acme-dns, MS CA and domain controller) are all in one network and have direct access. in this environment it's on Azure VMs. But I also reproduced the same with VMs running on VMware workstation.
any idea what could be the main issue here? is it possible to re-try to pull the certificate from the MS CA after the NETBIOS failure?
Logs from both acme.sh and a2c are attached here.
a2clog_amcesh.txt
acmeshlog.txt
The text was updated successfully, but these errors were encountered: