that long string is change every order, and as you select the manual you have to update the challenge response by yourself. did you do that?
4 Likes
Thanks for response @orangepizza , sorry but I am not getting this. Which long string changes every order? and how to update the challenge response?
let's try sudo certbot --apache and see if certbot is smart enough to figure it out by itself
4 Likes
What does that mean, exactly?
6 Likes
it just do load testing by opening list of urls we give and capture time required to launch set of pages.
And that results in some kind of error? Could you please share the exact error message?
6 Likes
The error provided in the first post suggests that this is a problem with the web server under load and has no relation to certificate issuance, Let's Encrypt, or Certbot.
7 Likes
I agree with linkp that this looks like a server failure under load.
But, is your error when connecting to user.dotcom-monitor.com
Because that domain is using a wildcard cert from Sectigo so wouldn't be a Let's Encrypt problem anyway
7 Likes
Yup, it does suggest that very much. Perhaps my request for confirmation wasn't necessary indeed. 
Not something for this Community I think.
5 Likes
Here is error message
**Cryptographic Error (100)**Authenticate failed. Reason: 'Authentication failed because the remote party has closed the transport stream.'.
Supplemental information: That is an old version of Certbot. Here is information on a newer one Certbot 2.1.0 Release
1 Like
Other than removing TSLv1.0[&1.1], and maybe the DHE ciphers, I don't see anything wrong with the TLS service.
That said, you may need to check the resources available to it.
- memory
- CPU
If all is in order and this problem continues...
I would suggest you try using another web server - like: nginx
4 Likes
That looks like a "connection reset" error, which is pretty normal to see during load testing. I think it's more than likely that the "Cryptographic error" and "authenticate failed" are red herrings and the underlying cause is a networking one.
My main question is whether it happens on every connection attempt from the load testing tool, or whether it just happens "eventually" during the load test.
The former (the load test fails immediately) would indicate that dotcom-monitor doesn't like the TLS configuration of your Apache server. This probably doesn't have anything to do with your certificate or Certbot, but would be more about ciphersuites and protocol versions. You can look at https://ssl-config.mozilla.org/ for hints about that.
(It could also be that you have a firewall that has blocked the dotcom-monitor server - some firewalls produce "connection reset" errors when they block a host).
The latter (the load test eventually fails with that error) is pretty normal and would have to do with the performance tuning of your operating system and web server.
7 Likes
Is there any possibility that SHA-1 and/or TLS v1.0/v1.1 is being used?
There is always that possibility.
Although the logs, dotcom-monitor, and the wire will know for sure, it doesn't seem to be very relevant from what has been given/shown.
When it can do it 1 time without error, but then can't do it 100 at a time, that seems more like an overload than a block or major misconfiguration.
4 Likes
That's all related to the LE ACME API while OP is testing a third party website. So I don't see any relation between this.
6 Likes
Yeah, the title of "Authenticate failed. Reason: ‘Authentication failed because the remote party has closed the transport stream" lead me down a wrong path. I have troubles sometimes with pronouns or implied nouns such as "remote party".
1 Like
thanks for reply, actually apache is must. Can change it due to compatibility of third party SSO.
2 Likes
Do they use SSO over HTTP or HTTPS [or both]?
Basically: Can the SSO be done on any other port [not 443]?
2 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.