What a timely comment @webprofusion . '
EFF announced Certbot v1.25 dropping 32bit Windows just hours ago
4 Likes
Windows apps and services tend to use the native SChannel support for TLS etc, this includes the http.sys kernel mode driver for handling http/s. So for instance IIS, MS Exchange, RDP etc. The disadvantage is this is OS level and is only updated by Microsoft.
Apps can opt to use their own tls etc implementations but that means they need to maintain that (trusts stores etc) and can't do port sharing. For instance, Certify can temporarily spin up a http challenge response service using http.sys, which doesn't interfere with normal IIS requests, but certbot uses pythons own http listener which can't share port 80. Likewise if you run nginx or apache these will lock port 80/443 so other apps can't use them.
6 Likes
This looks like a TYPO:
3 Likes
This kind of port sharing sounds like it is a Windows-exclusive feature.
2 Likes
You're right, it should be
-- standalone ^
I corrected it, thank you very much.
2 Likes
You may have missed the "before" keyword there. Windows Server 2022 and recent versions of Windows 10 and 11 do support TLS 1.3. But the last Windows Server version, 2019 (which was released in Oct 2018), does not.
Don't get me wrong. I would've hoped MS would be on the ball with support even before it was finalized and had it included (or at least back ported) in 2019. But I'm sure there are plenty of both technical and non-technical reasons it wasn't.
4 Likes
Yeah, that's the point. If your OS comes out in 2018 it's understandable not supporting TLS 1.3 at release day.
But not updating it to support it sounds just lazy.
2 Likes
It's a compelling incentive to upgrade though. heh
4 Likes
Yeah, but it's like Ubuntu LTS: it's old, it's very old most of the time.
If you install plain Debian you can at least pin some packages from unstable or testing -- Ubuntu doesn't even support that, its testing repos are old too!
2 Likes
No more spamming? What a pity.
In the new version 1.25.0 the hook scripts work under windows. There are still character set errors, e.g. if you output German umlauts in the script, but the scripts run error-free. Therefore, the installation via python is only necessary if you want to use plugins. Otherwise you can use the normal installation file.
Any program started in the hook script must also be terminated, otherwise certbot will wait for the program to exit before continuing its execution. That can't be changed, unfortunately. Way out: you do not start 'certbot renew' directly in the task scheduler, but in a batch file and then start the required programs in this batch file. If you want to make startup dependent on a successful renewal of a certificate, you have to work with environment variables that you can set in a deploy-hook.
-edit
Assignment of rights: After further testing I have to correct my opinion. The desired functionality is already available. Any process running with administrator or system privileges can easily access it. Each user who is to access the certificates is given read rights in the two folders live and archive with the value 'This folder, subfolders and files' for 'Apply To'.
1 Like
I think the issue with character sets depends on python directly, which is not happy if you use old encodings like iso-8859-15 instead of Unicode. (Python3 strings internally are utf-16, if I recall correctly)
2 Likes
It's a code page problem, with powershell and command line. Look at this.
1 Like
@SamLowryMOI Thank you for this, I was able to get Certbot installed on Win 7 by using Python 3.6.4, but then needed to update PIP before the Certbot installer could finish. It's only for a localnet usage so I don't care in it's win7, it's a very old machine that can't upgrade to 10, but it does it's job without complaint. Thank again
2 Likes
You're welcome, I'm glad I could help.
2 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.