Thomas S.

I don't want to exaggerate now, but if you are so insecure and already want to delete certificates, then you should strictly avoid the Internet. Alternatively, only separate, secure end-to-end encryption of all data transfers that you control all by yourself would remain. You are not fully secure on internet, it was so and it will be so in future.

Just in this moment I was looking at this post https://github.com/pyca/cryptography/issues/4011#issuecomment-389711206. I think it is a problem with missing OpenSSL libraries which are not in the cryptography package.

At this time I don't know exact what the problem is. I compile a updated version of HTTPSProxy under Python 3.4.4 to a little suite for XP (see my signature) and found that the package "cryptography v2.5" results in this error. So I step back to "cryptography v2.4.2" an it works OK.

Thanks! At last I have solved all problems, don't know right what the problem with Office 2010 was. May be that one update was not installed OK. All is set as here discussed and works well. Works here OK.

NO! Already done and work well. Makes no difference in this case.

Sorry for delayed answer YES, if I use http (http://www.update.microsoft.com/microsoftupdate/v6/default.aspx?ln=de) NO if same link as httpS (https://www.update.microsoft.com/microsoftupdate/v6/default.aspx?ln=de) In the last case I get a stop "Es besteht ein Problem mit dem Sicherheitszertifikat der Website" (certifikate error). If I disable the internet security option "Auf gesperrte Serverzertifikate prüfen" (Check on locked server certificates) it works immediatly without error, NO restart of IE8 needed, only reload the site. HTTP as good as HTTPS. Using the HTTPSProxy or not makes no difference. I have tried the httpS link in Firefox, and it give me the same warning, don't connect. Then I look at certificate locked in FF, copied the certificate and prooved it as "MS_Update.cer" into windows direct. IT IS VALID and points to www.update.microsoft.com I think that there is indeed a malconfiguration on server side. If the certificate is valid, why locked FF the link? The certificate is VALID... May be a intermediate certificate is missing in FF cert store, but this is only a suggestion. To much to research. At this point I am not going through the whole update, there is another problem with Office 2010 behind kb4461614 / kb4462174, without these update I can't run Office too!!!!! Must be a second problem... Certificate: MS_Update.cer

If you call MU via http there are no such calls. And it doesn't matter, also httpS works fine without extra pass-thru. And it solves not the initial problem within IE8 and certificate error... This MS update is a big mess! And BTW: I have errors with Office 2010 too - deinstalled 4462174 - but no effect, Office is down...

Regardless with or without HTTPSProxy the same error. I have restored a backup from 01/14/2019, wich worked definitly well at this time. But now the same problem. I found this: uncheck the internet security opton "Auf gesperrte Serverzertifikate prüfen" (Check on locked server certificates) and it suddely works without error. But this is not necessary on the notebook!? I now will take a look for an error on my certificate store. But on the other side: the certifikate is valid, if I look at the chain! Info: the yellow shield is comming up normal, no problem on this way... BTW: on both systems only www.update.microsoft.com for [SSL Pass-Thru] is needed.

Don't work at all...

Same here, but only on one PC (strange). On the notebook it is ok, and both are with the same configuration of TLS and HTTPSProxy, only "www.update.microsoft.com" is under "SSL Pass-Thru". If I play with the configuration of PCs HTTPSProxy, I get the old error "update certificate / PC wrong time" (old case, do I remembering right?) And from the past: every problem with this MU is gone after a few days. Do MS something on their servers to prevent to much connections?

It is not so easy, I think. In the meantime Oulook 2010 (Win XP 32bit) can connect direct to the email provider via TLS1.2. It now works without sTunnel (this was a older solution under XP to support POP / SMTP / IMAP via TLS1.2) Also IE can connect direct via TLS1.2 without proxy (but ciphers and certificate management is restricted). The question is if the newer .NET DLLs in XP support the call of higher TLS versions. Are they the same in XP as in Vista? Or have the XP versions a lower support? And it seems so that the SW uses minimum .NET 4.0.x (not 2.0) Under my actual updated Windows 7 (64bit) it works OK. But there is .NET 4.7.x present.

The two suggestions don't work. There are two dependencies, I think. First the OS must be able to support HTTPS TLS on higher level. This is done with the update for IE which support TLS 1.1 / 1.2 Second the .NET Framework else. So it makes sense that there are special updates from MS for the .NET Framework. May be there are some new API features for the higher TLS versions in the .NET Framework. Without this new DLLs the .NET application runs into an error.

I have a specific problem with a software that depends on .NET Framework. AlfBanco (online banking) cannot connect to the AlfBanco server. According to the manufacturer, a problem with the following background. It is likely that it cannot establish a connection to the remote server because it cannot establish such a connection in XP (2.0/3.0/3.5/4.0). TLS1.0 is the highest variant in .NET Framework, regardless the capabilities of XP, which can TLS1.2 after updating the system. MS Hotfixes for .NET Framework can only deal with this problem from Vista on. See here: https://support.microsoft.com/en-us/help/3154517/support-for-tls-system-default-versions-included-in-the-net-framework https://support.microsoft.com/en-us/help/3154518/support-for-tls-system-default-versions-included-in-the-net-framework Has anyone ever made any attempts to do this? Is it possible to port the hotfix for Vista 32bit on XP? I have no idea...

Of course, you can use it. But makes no sense if you need not the new functions built in. Oracle always republished two versions at the same time. Oracle itself has repeatedly pointed out that the use of the higher version number can be associated with additional problems, as new features have been released again and again with the higher version. Therefore, as a matter of principle, only the security updates (lower version number) should be installed in order to avoid new problems, including new security vulnerabilities. Possible that you close a door an have open two others...

@Dave-H I do not recommend v152 at last installation under XP, if you do not change the files to v191. Latest recommended version to install in XP was v151. v152 is a version with added new functions and may have more problems as the original version with only security updates (v151).

Yes. As described here in this older advice At last copy one file to have the new control panel: copy /y C:\Programme\Java\bin\javacpl.cpl C:\WINDOWS\system32 I do not have any problems with the latest v191. If you wish to correct ALL STRINGS to get always displayed the right version info take a look in the registry. But this is NOT required, only cosmetic! Excample entries: [HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment\1.8.0_191] [HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment\1.8.0_191\MSI] "PRODUCTVERSION"="8.0.1910.12" "FullVersion"="1.8.0_191-b12" [HKEY_LOCAL_MACHINE\SOFTWARE\JreMetrics] "JreVersion"="1.8.0_191-b12" [HKEY_CLASSES_ROOT\Installer\Products\4EA42A62D9304AC4784BF2238110150F] "ProductName"="Java 8 Update 191-b12" [HKEY_CLASSES_ROOT\Installer\Products\4EA42A62D9304AC4784BF2238110150F\SourceList] "PackageName"="jre1.8.0_191.msi" # # # "DisplayVersion"="8.0.1910.12" "InstallDate"="20181020" "DisplayName"="Java 8 Update 191"

v191 has several security updates -> see https://www.oracle.com/technetwork/java/javase/8u191-relnotes-5032181.html v192 has a extra new feature -> see https://www.oracle.com/technetwork/java/javase/8u192-relnotes-4479409.html With v191 you are as safe as possible, v192 is not needed. In the past there where alsways two versions, one with security updates ans one with new features. Recommended was always the lower v number to avoid problems with the new features. Only if you need the new feature go to the higher v number.

Yes, it is. But who will do this? And who tests and supports this version? I ask Michał Trojnara - he is too busy...

@404notfound, @Dibya and @FranceBB Hello all. Nice work, but... If a project requires a development environment, this must also fully run. If Python 3.7 under XP is required as a development environment for HTTPSProxy under XP, Python 3.7 must be fully installable and supported. It is unacceptable that already the development environment must be sought together until it runs without error. The Python modules need to be updated regularly, there are enough tests therefor. I would like to supply SW to my user, that is not develloped on a possibly faulty development environment... Sorry, but so your project is not suitable for a development of HTTPSProxy (at this time) i think.

I use sTunnel only for receiving (POP) and sending (SMPT) the emails with Outlook. HTTPSProxy is not able to handle this protocols, and you need to address the email server TLS ports 995 / 465 (HTTPS is 443). But for display purposes, especialy pictures embedded in emails and downloaded direct via HTTPS from many different hosting servers (in Outlook the MSWord and IE / system functions are used) HTTPSProxy is also needed. So it depends of the way Eudora must establish a connection to your email provider (i don't know this).

I use Outlook 2010 as email client. To get in contact with my email providers it is neccessary to have modern TLS protocols, TLS1.0 / SSL is no more supported. And to solve this problem I use sTunnel (latest version for 32bit is 5.49). The advantage of sTunnel is that the Windows certificate storage can be used, which greatly simplifies the configuration in this case. So sTunnel only needs to be installed and activated as a service, as well as using this simple configuration (example of stunnel.conf): debug = 4 engine = capi options = NO_SSLv2 options = NO_SSLv3 options = NO_TLSv1 [gmx-pop3s] client = yes EngineID = capi accept = localhost:xxxx connect = pop.gmx.net:995 [gmx-smpts] client = yes EngineID = capi accept = localhost:yyyy connect = mail.gmx.net:465 In Outlook the local ports are set as default connection (server localhost and port POP xxxx / SMPT yyyy) Thats all. It works also for other email clients, so this may be a good advice for a configuration.

New cacert.pem from Curl released (RootCA certificates used by HTTPSProxy). If you do not have AutoUpdate enabled (provided by Launcher) update the file manually as soon as possible. This file is also used by sTunnel (here renamed to ca-certs.pem), so you can copy it to the config folder of sTunnel. Header: ## ## Bundle of CA Root Certificates ## ## Certificate data from Mozilla as of: Wed Dec 5 04:12:10 2018 GMT ## ## This is a bundle of X.509 certificates of public Certificate Authorities ## (CA). These were automatically extracted from Mozilla's root certificates ## file (certdata.txt). This file can be found in the mozilla source tree: ## https://hg.mozilla.org/releases/mozilla-release/raw-file/default/security/nss/lib/ckfw/builtins/certdata.txt ## ## It contains the certificates in PEM format and therefore ## can be directly used with curl / libcurl / php_curl, or with ## an Apache+mod_ssl webserver for SSL client authentication. ## Just configure this file as the SSLCACertificateFile. ## ## Conversion done with mk-ca-bundle.pl version 1.27. ## SHA256: 35b415062acb8c2c27607083b5b3bec8f4ff57463c9b9f06db3e8df3ea895592 ##

As I said: I am not able to run python.exe The patch does not help. python.exe - System error NtCreateFile API failed. This error should not be returned to any application because it is a placeholder for the Windows redirector so that it can use its internal error allocation routines.

Up to date, not all AV manufacturers have responded. But the most important ones have classified the file as not dangerous. After all, there are currently only 12 false alarms with very different alerts...

Without the ability to install or update modules, more complex scripts are not possible. Similarly, no distribution to an EXE can be produced and tested under XP (requires the working module pyinstaller).