Clients on windows 7 not able to connect after certbot upgrade

We have a system where we have an old client problem written in Visual C++ 2008 that reads data from our web server via https. We recently upgraded our web server and installed the latest version of certbot.

The old server was using certbot 0.31.0
The new server is using certbot 2.6.0

As soon as our certificates were renewed a number of users who are still running the 32 bit version of windows 7 could no longer connect to our server.

My question is, is there a way to get the new version of certbot to generate its SSL in a way that is compatible with the older version.

This depends on your webserver config.

Go on and select the configuration that works for you.


Also, check that Certbot created an RSA cert. The default changed in 2.0 but it should have retained the type but that was a big jump in versions so maybe something went wrong.


Also/2, keeping a Windows 7 machine on the public internet in 2023 is only generally seen as "asking for trouble"


Hi @joefremont, and welcome to the LE comnunity forum :slight_smile:

It is likely some cipher mismatch.
But without the domain name, we can only guess.

Win7 supports:
[So, I don't immediately think it is an RSA / ECDSA issue]


You could stick a proxy in between them and serve whatever "weak" cipher is needed to make that old app connect.
[without weakening the entire server to the Internet]


I agree that using windows 7 is asking for trouble but its not my call, the members use what they want.
I just tried generating with RSA and did not fix the problem.
The site is
BTW, its not a 32bit issue as a member who using win7/64 is also having the problem.

I have setup a relay machine on an instance that is still running the same old OS as the previous server so that it will proxy pass into the main server, and from what reports I have seen that does work.

1 Like

It is not likely a cert issue.
It is a cipher issue.
What ciphers does the vhost config file use?


Check the proxy logs and see what cipher the app uses to connect.
[you may have to turn up the logging to see the cipher used]


They don't, if you set your ciphers like this. :smiley:


The reason I believe it is a cert issue is that when we moved to the new system, I copied all the files over, including the old generated certs and everything was working, that was on Sept 3. On Sept 26 the cron job triggered that renewed the certificates and that is when the problems started.

1 Like

True, but would rather not use them as members.

When did you upgrade certbot?

And what else happened between Sept. 3 and 26?


When I started building the new server I got the latest version, that would have been August 4. No real changes system wise after it went live on the 3rd..

What ciphers did it use on Sept 3?


If you don't need the DHE ciphers, I would remove them:

OR, at least, deprioritize them.


Hold the presses!

2008 app...
Does it do TLSv1.2?
OR just TLSv1.0?


I rechecked the configs, it was using RSA, but over this last weekend but regenerated the SSL and it generated with ecdsa.

What ciphers does the vhost config file use?

Could not find this vhost file, its what ever certbot installed by default.

Newer versions of certbot will disable weak ciphers and protocols.

This is what is being served now:
I suspect the app requires TLSv1.0
[and possibly some specific, now considered weak, cipher]


The latest cert only covers the name Your earlier certs had that mixed with others such as the root domain.

So, this would have been a new cert as far as Certbot knew. That explains why it was ECDSA but the most recent is RSA as you say.

Maybe this ties into what @rg305 says about the TLS version? I am pretty sure older Win7 don't support later TLS.

Could Certbot have updated your server config too because of this differently named cert?