Authenticate failed. Reason: 'Authentication failed because the remote party has closed the transport stream

Help
1

I am getting cryptographic error whenever I am running load testing. I am using certbot 0.31.0 on Apache/2.4.18. Is this error due to low certbot version? Will it fix if we use latest certbot version?

My domain is:https://iteachmsu.venturit.org/

I ran this command: ran load testing to https://user.dotcom-monitor.com/

It produced this output: Resulted into Cryptographic Error (100) authenticate failed. Reason: 'Authentication failed because the remote party has closed the transport stream

My web server is (include version): Apache/2.4.18

The operating system my web server runs on is (include version): Ubuntu

My hosting provider, if applicable, is: AWS

I can login to a root shell on my machine (yes or no, or I don't know):

I'm using a control panel to manage my site (no, or provide the name and version of the control panel):

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):
certbot version: 0.31.0

2

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
3

Thanks for response @orangepizza , sorry but I am not getting this. Which long string changes every order? and how to update the challenge response?

4

let's try sudo certbot --apache and see if certbot is smart enough to figure it out by itself

4 Likes
5

What does that mean, exactly?

6 Likes
6

it just do load testing by opening list of urls we give and capture time required to launch set of pages.

7

And that results in some kind of error? Could you please share the exact error message?

6 Likes
8

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
9

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
10

Yup, it does suggest that very much. Perhaps my request for confirmation wasn't necessary indeed. :slight_smile:

Not something for this Community I think.

5 Likes
11

Here is error message

**Cryptographic Error (100)**Authenticate failed. Reason: 'Authentication failed because the remote party has closed the transport stream.'.

12

Supplemental information: That is an old version of Certbot. Here is information on a newer one Certbot 2.1.0 Release

1 Like
13

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
14

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
15

Is there any possibility that SHA-1 and/or TLS v1.0/v1.1 is being used?

16

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
17

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
18

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
19

thanks for reply, actually apache is must. Can change it due to compatibility of third party SSO.

2 Likes
21

Do they use SSO over HTTP or HTTPS [or both]?

Basically: Can the SSO be done on any other port [not 443]?

2 Likes