I downloaded Certbot for the Win7(x86) server from https://dl.eff.org/certbot-beta-installer-win32.exe and installed it. Then, I added C:\Program Files\Certbot\bin
to the system’s path and double clicked C:\Program Files\Certbot\run.bat
. In the command line I typed certbot --help
, but it popped up a python.exe
system error window which tells the computer lacks api-ms-win-core-path-l1-1-0.dll
. I've tried best to find ddl file on the internet but didn't find any compatible version. If there's someone who can kindly tell what should I do next? Thanks!
Upgrade Win7
Windows 7 support ended on January 14, 2020 - Microsoft Support
You could also try another Windows ACME client:
ACME Client Implementations - Let's Encrypt (letsencrypt.org)
Thanks a lot! I am always following your advice.
Is there any client among them that doesn't require an open 80 port?
If you can find an ACME client for your system that supports
TLS-ALPN-01
, then that can be fully automated.
Hi, @rg305 . I am using win-acme on my Win7(32-bit) server and it seems to work well. I have tried the so called TLS-ALPN-01
method, but it failed. The command line is as follow:
I beg your advice!
Your server needs to be reachable from the public internet.
Yes, I have a public IP address. But, what is not so lucky is that my 80 port is not available. Now my server can only be reached via [domainname]:[port]
, e.g. my.domain.name:7777
.
Can I get a certificate in this situation?
tls-alpn-01
uses port 443.
Oh...What can I do if my 443
port is also unusable?
Use the dns-01
challenge.
But my domain name is obtained from the router‘s management web page. I didn't find where I can add a TXT record if I use the dns-01
challenge.
Am I out of luck with the certificate?
If you can't open port 80, can't open port 443, and don't control your own DNS, then yes, you're out of luck unless and until you change at least one of those things.
thanks!
If you don't have any connectivity on ports 80 or 443, chances are you weren't trying to set up a public webserver? If it's just for you, you could also just use a self-signed certificate. See Google on how to do that.
Thanks a lot @Osiris! As you said, I am using a self-signed certificate now. But considering that it is not inherently safe, it always makes me feel uncomfortable. In this regard, do you have any way to distinguish the authenticity of the certificate? That is to say, how to judge that my certificate has not been forged by hackers? (I know little about certificates.)
A self-signed cert provides the same TLS security as a public CA cert. If you are the only one connecting on port 7777 you should be able to recognize your own certificate.
You could even add that self-signed cert as a trusted one on your own devices so that browser's don't show a warning about it.
To what extent can a forged certificate be close to a real certificate? What's the difference? Obviously, my location, organization, email address, etc. may be fraudulently used, so how to confirm that the certificate that the browser reminds me is really my own? In addition, if I let the browser trust my real certificate, can a fake certificate deceive the browser? Sorry, maybe I have too many questions and they are very low...
If you add the self signed cert to the system or browsers cert store, you should get a warning if someone would forge a fake cert.
It can only have the same FQDN [same domain name].
But it could never have the same root.
It should never have any trusted root path and would never be trusted.