Err Connection Reset: Accessing my HTTPS Website from Corporate Proxy


My website is inaccessible from a particular workplace proxy upon activating a HTTPS encryption. Switch back to a HTTP connection and it works. I have also confirmed that the website is working from an outside internet connection and Qualys SSL Labs issued an A+ Rating.

Server Configuration

  • Ubuntu 16.04 with Apache 2.4.18
  • SSL Certificates issued from Let’s Encrypt (

Ruled Out

  • Certificate Provider: Managed to access other sites encrypted with Let’s Encrypt certificates.
  • Keyword Block: This would mean that my HTTP site would not be accessible as well but that is not the case.


Error Logs

I have managed to capture the error logs when a client from the corporate proxy tries to access the website.

[Fri Sep 16 10:45:13.850364 2016] [ssl:info] [pid 29221] [client] AH01964: Connection to child 3 established (server
[Fri Sep 16 10:45:13.850692 2016] [ssl:trace2] [pid 29221] ssl_engine_rand.c(126): Seeding PRNG with 656 bytes of entropy
[Fri Sep 16 10:45:13.850800 2016] [ssl:trace3] [pid 29221] ssl_engine_kernel.c(1970): [client] OpenSSL: Handshake: start
[Fri Sep 16 10:45:13.850828 2016] [ssl:trace3] [pid 29221] ssl_engine_kernel.c(1979): [client] OpenSSL: Loop: before/accept initialization
[Fri Sep 16 10:45:13.850907 2016] [ssl:trace4] [pid 29221] ssl_engine_io.c(2056): [client] OpenSSL: read 11/11 bytes from BIO#562b352aea90 [mem: 562b352bc180] (BIO dump follows)
[Fri Sep 16 10:45:13.850977 2016] [ssl:trace4] [pid 29221] ssl_engine_io.c(2056): [client] OpenSSL: read 175/175 bytes from BIO#562b352aea90 [mem: 562b352bc18e] (BIO dump follows)
[Fri Sep 16 10:45:13.851043 2016] [ssl:debug] [pid 29221] ssl_engine_kernel.c(2096): [client] AH02043: SSL virtual host for servername found
[Fri Sep 16 10:45:13.851059 2016] [core:debug] [pid 29221] protocol.c(1891): [client] select protocol from , choices=h2,spdy/3.1,http/1.1 for server
[Fri Sep 16 10:45:13.851074 2016] [ssl:debug] [pid 29221] ssl_engine_kernel.c(2096): [client] AH02043: SSL virtual host for servername found
[Fri Sep 16 10:45:13.851129 2016] [ssl:debug] [pid 29221] ssl_util_stapling.c(754): AH01951: stapling_cb: OCSP Stapling callback called
[Fri Sep 16 10:45:13.851167 2016] [ssl:debug] [pid 29221] ssl_util_stapling.c(762): AH01952: stapling_cb: retrieved cached certificate data
[Fri Sep 16 10:45:13.851188 2016] [socache_shmcb:debug] [pid 29221] mod_socache_shmcb.c(528): AH00835: socache_shmcb_retrieve (0xef -> subcache 3)
[Fri Sep 16 10:45:13.851199 2016] [socache_shmcb:debug] [pid 29221] mod_socache_shmcb.c(880): AH00849: match at idx=0, data=0
[Fri Sep 16 10:45:13.851207 2016] [socache_shmcb:debug] [pid 29221] mod_socache_shmcb.c(538): AH00836: leaving socache_shmcb_retrieve successfully
[Fri Sep 16 10:45:13.851235 2016] [ssl:debug] [pid 29221] ssl_util_stapling.c(314): AH01933: stapling_get_cached_response: cache hit
[Fri Sep 16 10:45:13.851244 2016] [ssl:debug] [pid 29221] ssl_util_stapling.c(697): AH01953: stapling_cb: retrieved cached response
[Fri Sep 16 10:45:13.851330 2016] [ssl:debug] [pid 29221] ssl_util_stapling.c(813): AH01956: stapling_cb: setting response
[Fri Sep 16 10:45:13.851348 2016] [ssl:trace3] [pid 29221] ssl_engine_kernel.c(1979): [client] OpenSSL: Loop: unknown state
[Fri Sep 16 10:45:13.851366 2016] [ssl:trace4] [pid 29221] ssl_engine_io.c(2056): [client] OpenSSL: write 117/117 bytes to BIO#562b352ba920 [mem: 562b352c42d3] (BIO dump follows)
[Fri Sep 16 10:45:13.851422 2016] [ssl:trace3] [pid 29221] ssl_engine_kernel.c(1979): [client] OpenSSL: Loop: unknown state
[Fri Sep 16 10:45:13.851452 2016] [ssl:trace4] [pid 29221] ssl_engine_io.c(2056): [client] OpenSSL: write 2472/2472 bytes to BIO#562b352ba920 [mem: 562b352bc183] (BIO dump follows)
[Fri Sep 16 10:45:13.851487 2016] [ssl:trace3] [pid 29221] ssl_engine_kernel.c(1979): [client] OpenSSL: Loop: unknown state
[Fri Sep 16 10:45:13.851497 2016] [ssl:trace4] [pid 29221] ssl_engine_io.c(2056): [client] OpenSSL: write 540/540 bytes to BIO#562b352ba920 [mem: 562b352bc183] (BIO dump follows)
[Fri Sep 16 10:45:13.851512 2016] [ssl:trace3] [pid 29221] ssl_engine_kernel.c(1979): [client] OpenSSL: Loop: unknown state
[Fri Sep 16 10:45:13.855654 2016] [ssl:trace4] [pid 29221] ssl_engine_io.c(2056): [client] OpenSSL: write 338/338 bytes to BIO#562b352ba920 [mem: 562b352bc183] (BIO dump follows)
[Fri Sep 16 10:45:13.855690 2016] [ssl:trace3] [pid 29221] ssl_engine_kernel.c(1979): [client] OpenSSL: Loop: unknown state
[Fri Sep 16 10:45:13.855703 2016] [ssl:trace4] [pid 29221] ssl_engine_io.c(2056): [client] OpenSSL: write 9/9 bytes to BIO#562b352ba920 [mem: 562b352bc183] (BIO dump follows)
[Fri Sep 16 10:45:13.855713 2016] [ssl:trace3] [pid 29221] ssl_engine_kernel.c(1979): [client] OpenSSL: Loop: unknown state
[Fri Sep 16 10:45:13.855730 2016] [ssl:trace4] [pid 29221] ssl_engine_io.c(2056): [client] OpenSSL: write 3476/3476 bytes to BIO#562b352b9870 [mem: 562b352c9340] (BIO dump follows)
[Fri Sep 16 10:45:13.855741 2016] [core:trace6] [pid 29221] core_filters.c(525): [client] core_output_filter: flushing because of FLUSH bucket
[Fri Sep 16 10:45:13.855844 2016] [ssl:trace3] [pid 29221] ssl_engine_kernel.c(1979): [client] OpenSSL: Loop: unknown state
[Fri Sep 16 10:45:13.855861 2016] [ssl:trace3] [pid 29221] ssl_engine_kernel.c(1979): [client] OpenSSL: Loop: unknown state
[Fri Sep 16 10:45:14.215543 2016] [ssl:trace4] [pid 29221] ssl_engine_io.c(2065): [client] OpenSSL: I/O error, 5 bytes expected to read on BIO#562b352aea90 [mem: 562b352bc183]
[Fri Sep 16 10:45:14.215665 2016] [ssl:trace3] [pid 29221] ssl_engine_kernel.c(2008): [client] OpenSSL: Exit: error in unknown state
[Fri Sep 16 10:45:14.215688 2016] [ssl:trace3] [pid 29221] ssl_engine_kernel.c(2008): [client] OpenSSL: Exit: error in unknown state
[Fri Sep 16 10:45:14.215723 2016] [ssl:debug] [pid 29221] ssl_engine_io.c(1227): (70014)End of file found: [client] AH02007: SSL handshake interrupted by system [Hint: Stop button pressed in browser?!]
[Fri Sep 16 10:45:14.215763 2016] [ssl:info] [pid 29221] [client] AH01998: Connection closed to child 3 with abortive shutdown (server

Would gladly appreciate if anyone could shed some light on why some HTTPS websites do not work through the corporate proxy.

A+ on SSL Labs indicates that your server uses fairly modern cipher suites. It’s possible that your proxy is unable to use any of these, similar to how older web browser (think: IE 6) would be unable to visit such a site.

My recommendation would be try the cipher suites recommended by Mozilla’s SSL Configuration Generator in the “Intermediate” or “Old” setting. To do that, you’d replace the SSLProtocol and SSLCipherSuite directives in your apache configuration with the values provided by that site.

If things work with the intermediate settings, you should be okay with those. These ciphers aren’t the best out there, but plenty of big sites think they’re good enough. If things only work with the old settings, I’d definitely look into updating or replacing that proxy rather than changing your server configuration, as those ciphers and protocol are considered fairly insecure nowadays.


@pfg, that’s a good suggestion.

In 2012 Jeff Jarmoc pointed out that using proxies this way can result in diminished security because the proxies’ TLS clients are weaker against some security threats than the browsers’ would be. (One reason can simply be that the proxy software probably isn’t updated nearly as frequently as browser software would be.)

1 Like

I’ve taken your recommendation and tested it with the following settings on Mozzilla’s SSL Configuration Generator.

Unfortunately, even with the “Old” setting, the site is still not working for those users behind the proxy. It still shows an A+ on SSL Labs though. I’ll be leaving the server configured with the cipher suite recommended for any further testing if needed for the next few days.

Perhaps there could be something else I missed out? Twitter is also graded an A+ and the site works for the users.

Error Messages

Internet Explorer - "The proxy server isn’t responding"
Google Chrome - "This site can’t be reached. The connection was reset. [ERR_CONNECTION_RESET]"
Firefox - "Secure Connection Failed"


I realised that my OCSP is not accessible.

Twitter has their CRL & OCSP that is accessible.

This indicates that the change did not go into effect. Was the domain in question I just checked and noticed that this domain is hosted behind CloudFlare. In that case, your browser does not connect directly to your server, but rather to CloudFlare. CloudFlare has a separate certificate for your domain (not from Let's Encrypt), and you can't really change the TLS configuration since that's up to CloudFlare. At least for this domain, Let's Encrypt is not really part of the equation.

What kind of error are you getting? Could you run traceroute if you can't connect at all?


I can confirmed the changes were applied as changing the cipher suite to ALL:+LOW caused the grading to be capped at B on SSL Labs. I’ve attached my configuration file for your reference.

<IfModule mod_ssl.c>
<VirtualHost *:443>

SSLCertificateFile /.../fullchain.pem
SSLCertificateKeyFile /.../privkey.pem


Header always set Strict-Transport-Security "max-age=15768000"


# intermediate configuration, tweak to your needs
SSLProtocol             all -SSLv3
#SSLCipherSuite          ALL:+LOW
SSLHonorCipherOrder     on
SSLCompression          off
SSLSessionTickets       off

# OCSP Stapling, only in httpd 2.3.3 and later
SSLUseStapling          off
SSLStaplingResponderTimeout 5
SSLStaplingReturnResponderErrors off
SSLStaplingCache        shmcb:/.../ocsp(128000)

# vim: syntax=apache ts=4 sw=4 sts=4 sr noet

No it is

There were no error messages and the browser just shows a blank page. Other OSCP sites will download a file. Anyway, OCSP Stapling is disabled and I believe it shouldn’t be the cause of this issue.

Apparently the tracert command in cmd will not work behind the proxy as they might have blocked some of the protocols. Running it outside the proxy shows the destination at which I believe is not the actual destination.

The empty page you’re getting is fine. A real OCSP query would send other parameters (i.e. not simply do a GET /).

Let’s try the exact same cipher suites used by


If that doesn’t change anything, we know it’s likely not protocol/cipher-related.

There are a few other differences between those servers, most of which I don’t think would have any effect on a proxy, but who knows what these things care about. :smile: Here’s a list:

  • supports session resumption.
  • supports OCSP stapling. If the proxy indeed has problems talking to Let’s Encrypt’s OCSP but supports stapling, that could be an explanation. I think this should be enough to enable stapling:
SSLStaplingResponderTimeout 5
SSLStaplingReturnResponderErrors off
SSLStaplingCache        shmcb:/var/run/ocsp(128000)```
 - `` supports NPN, your server supports ALPN. This is related to the `openssl` version you're using, NPN is supported by older versions of `openssl` while newer ones support ALPN. If you want to rule out that this is the cause, you'd have to spin up a new web server with `openssl` < `1.0.2`, e.g. Ubuntu 14.04. Wouldn't bother with this until everything else is ruled out.
1 Like

Well that’s unfortunate… It still does not work behind the proxy :sob:

I have also implemented OCSP stapling on our site and we are still facing the issue.

That leaves us with session resumption and NPN support?

Very odd. :confused:

I don’t think session resumption and NPN are likely candidates, as this should be a fairly common configuration, so odds are many sites would break if your proxy had problems with that. Then again, this is the last TLS-related difference between your site and I can think of, so who knows, maybe it’s a weird combination of things and one of these two is actually the culprit.

1 Like

Very odd indeed.

I totally agree. But then again, I hear there are quite a number of sites that are not accessible with no observable pattern.

Would it be relatively easy to implement session resumption or NPN to see if it might be the cause?


I’ve found another website supporting session resumption and NPN that is not accessible behind the proxy.

Update 2:

A few of my colleagues realised it may be due to the root certificate not being trusted by the proxy server. Namely DST Root CA X3 and AddTrust External CA Root. The root certificate is the next thing that is similar across all sites that doesn’t work behind the proxy which we’ve previously mentioned.

Why still works may be due to a 2nd certificate that is shown in SSL Labs from IdenTrust Commercial Root CA 1. Guess the next thing to try changing our Certification Authority and I’ll keep you updated.

The second certificate shown by SSL Labs should only be relevant if your proxy doesn’t support SNI - otherwise, it would only see the certificate chaining up to the DST root. If it actually doesn’t support SNI and gets the certificate chaining up to “IdenTrust Commercial Root CA 1”, it should still fail as that certificate doesn’t include the domain (only and Then again, based on the things these proxies get wrong sometimes, it wouldn’t surprise me if they skipped the hostname check. :slight_frown:

You are right. Even after trying with a different Certification Authority, the website is still not accessible.

I think we would have to look at other areas since we’ve ruled out this list. I’ll continue researching :slight_smile: By the way, the domain in question has been moved to

Is there a possibility that the interactive installation that I used in the beginning could have modified some of the SSL configuration?

I was intending to start another server from scratch but would like to eliminate that possibility first.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.