Certbot install on server 2008 r2 but won't run

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:
I ran this command:
c:\program files x(x86)\certbot> certbot --help
It produced this output:
certbot is not recognized as an internal or external command, operable program, or batch file.
My web server is (include version):
The operating system my web server runs on is (include version):
2008 r2
My hosting provider, if applicable, is:

I can login to a root shell on my machine (yes or no, or I don't know):
Well, yes, I run cmd.exe as administrator
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 won't run. It seems to install just fine. But after that, nothing. Does it not run on Server 2008 R2? Too old?

Hi @papajon_0s1, and welcome to the LE community forum :slight_smile:

What shows?:
dir c:\certbot.* /s


Hmmm..... I'll get back into this tomorrow, but there isn't a c:\certbot folder. Odd.


I'm not looking for such a folder [nor in such a folder].
It looks for anything named "certbot.*" starting from the folder "c:\" and then through all subdirectories "/s".


Windows Server 2008 (including R2) went out of extended support over two and half years ago. Unless you have purchased all three years of the ESU subscription for it, that's how long it's been without security updates. Regardless of whether Certbot can run on it, connecting that OS to the internet is a danger both to itself and others.


Ok; Here is the raw result of that command:

Volume in drive C has no label.
Volume Serial Number is D866-560D

Directory of c:\Program Files (x86)

07/05/2022 03:58 PM Certbot
0 File(s) 0 bytes

Directory of c:\Program Files (x86)\Certbot

03/01/2022 03:48 PM 183,198 certbot.ico
1 File(s) 183,198 bytes

Directory of c:\Program Files (x86)\Certbot\bin

03/01/2022 03:49 PM 97,848 certbot.exe
1 File(s) 97,848 bytes

Directory of c:\Program Files (x86)\Certbot\pkgs

07/05/2022 03:58 PM certbot
0 File(s) 0 bytes

Directory of c:\ProgramData\Microsoft\Windows\Start Menu\Programs

07/05/2022 03:58 PM 1,833 Certbot.lnk
1 File(s) 1,833 bytes

Directory of c:\Users\All Users\Microsoft\Windows\Start Menu\Programs

07/05/2022 03:58 PM 1,833 Certbot.lnk
1 File(s) 1,833 bytes

 Total Files Listed:
           4 File(s)        284,712 bytes
           2 Dir(s)  82,338,549,760 bytes free

I don't use Certbot on Windows but is the \bin folder in your PATH?


Good question. Originally, it was not. I added it in there, but got the same results. I also noticed that if I drop into the /bin folder and run the command I get a Python error "The program can't start because api-ms-win-core-path-l1-1-0.dll is missing from your computer. Try reinstalling the program to fix the problem". So, I did reinstall, same result. Tried a few differing versions, same result. I even went and grabbed the DLL from elsewhere, same result. Truly curious.


Something seems fundamentally wrong with the install. Adjusting the PATH should have found at least the exe. You might have better luck asking on the Certbot github. The devs might see it quicker.

This forum is for Let's Encypt. We often deal with Certbot issues and ones for other ACME clients. But, some problems better dealt with by the devs for that software. (in Certbot's case that's EFF).

Or, try using one of the other Windows acme clients from that Let's Encrypt list. Although, your system is quite old and I can't vouch for which ones support it.


Thanks for the update, much appreciated. I'll give your suggestions a try.

1 Like

Sorry, your time will be better spent migrating to a new version of Windows. You can probably get this working but you'll need to move your application eventually, so I'd recommend to do it now.

If your site will be connected to the internet then this is likely the minimum you need to do before proceeding with any other activities, or you risk getting p0wned by a script kiddie.

If the site is internal only, then you'll need to use DNS validation etc and using an outdated client won't help (new certbot is the 64-bit version, the install instructions still link to the old 32 bit version).

If your webserver is IIS and you have .net 4.6.2 or higher installed then you can theoretically use https://certifytheweb.com, you'll just get a bunch of warnings about your OS etc (and you can't use SNI which is a major drawback of using an old OS if hosting multiple sites), but really it's best to move to a new OS first then worry about configuration of certificates.


Thanks for the comments but yes, we are well aware we have some very very old machines and software here. We don't have a choice with the old yet exceedingly expensive production equipment that runs proprietary software that may only run on specific O/S (some be design and some if we upgrade we void vendor warranties). It's just not financially feasible to replace this equipment, that can cost 6-7 figures easy, for a medium sized company, especially in this current economy. We aren't talking just upgrading an operating system here, it's the entire production device and then you add in the cost of training and maintenance etc etc etc. Believe me I've been down this path many many many times and honestly, I'm a bit surprised more IT folks haven't run into this sort of thing and understand the dilemma that it isn't just the cost of servers, storage, and software, it can be a lot more than that.

And not you, but another response was seriously rude with their comments about security when they didn't know all the facts and what our company has gone through and our extensive efforts to be as secure as possible faced with the situation we live with. We don't have the funds, personnel, or resources of a large corporation, it's just not the world every IT person lives in. So it was really disappointing to come here and ask a question to try and make our old equipment as secure as we can and just get harassed for doing so (not you, that other person). I mean, people come here for some help, the last thing they are looking for is a accusatory lecture (again, not you, that other person).

Ok, done venting!!! Thanks for the last suggestion about certifytheweb.com, I'll check it out as well.


Have you considered placing the entire system behind an HTTPS proxy (and firewall) ?


Thanks, yes I've seen this before with things like CAD control and other process automation. Presumably this device doesn't need to be on the internet and the reason you need a cert is just so internal users can browse to the app without a certificate error. Note that you can get a cert using another machine then deploy it to that machine (either manually on a regular basis or via scripting).


I've dealt with a lot of these industrial/mfg systems in the past, and IMHO this is one of the best approaches, but there is a better potential option: if possible, you can drop that machine down to HTTP and run everything behind a (modern) proxy that will handle the SSL. This solution is not applicable to all situations, but it is generally better because it allows you to keep the SSL ciphers and TLS versions updated.

In any event, I would not bother trying to run Certbot or anything else on these machines - you will constantly face an uphill battle as the modern software is upgraded. I would invest your time, energy, and sanity in creating and documenting the processes to (i) obtain certificates on another machine, (ii) deploy certificates to the target machine(s), and (iii) update the trust store on the target machine(s).


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