"Update Notepad++" requires certificate support (InitializeSecurityContext failed)

[mattisking]

Obviously a low priority issue, I cannot use the Update functionality in Notepad++ at work. All of our HTTP/HTTPS traffic goes through a certificate which is required. IE and Chrome, for instance, work fine browsing the internet since the certificate is assigned automatically to all accounts in our network (Chrome uses IE settings). Firefox, however, requires the installation of that same certificate under it's "Security Devices" section under Advanced. I have to set that up manually. Notepad++ seems to be having the same kind of issue when it checks for an update. I get the following message: "schannel: next InitializeSecurityContext failed: Unknown error (0x80092012) - The revocation function was unable to check for revocation for the certificate." It would be nice to be able to update within Notepad++ as I can from home without having to check the website for updates. I'd call some kind of support here a "nice to have" feature as I suspect this doesn't affect that many people, but since this tool is so fantastic for Software Developers and I assume there are plenty of us working in a large corporation with various security settings in place, it might be pretty useful.

[milipili]

Feel free to re-open this ticket if you still have problem

[theit]

I also have this problem at work. Is there any solution or workaround for this?

[Eagle3386]

@milipili: 👍 from my workplace. Please enable updater to work under such circumstances.

[milipili]

@theit, @Eagle3386 Which operating system are you using ?

[theit]

@milipili: We're using Windows 8.1.

[milipili]

@donho Reopening this issue since it seems we still have problems with a supported version of Windows.

[Eagle3386]

@milipili We're on Win 7 x64 Enterprise.

[donho]

@milipili If I do understand the problem, the issue is updating notepad++ failed due to the https (certificate checking failed)?

[theit]

@milipili: I forgot to mention that similar to @Eagle3386 we use the x64 Enterprise version, but I've seen the same behaviour under 32- and 64-bit versions of virtual machines with Windows 7 in our network.

@donho: Yes, that seems to be the cause of this error. To browse the Internet from within our company's network we have to use a proxy that uses a certificate signed by an inhouse root CA. This is installed per default in the Windows-internal certificate store and additionally in Firefox's profile so accessing the Internet using a browser. Obviously Notepad++ behaves similar to Firefox, i.e. has/uses its own certificate store, right?

[Eagle3386]

@donho: Our company's proxy works just as @theit's one does.

[milipili]

Firefox uses indeed its own certificate store (which should be fixed soon I've been told) but it should not be the case for n++. N++ should already rely on the system itself. That said I wouldn't be surprised if there was a corner case with proxies in https.

Just to avoid any misunderstanding, is that correct ?

n++  --> [proxy via https (inhouse CA)] --> internet (https and/or http)

[milipili]

Do you know if your proxy requires some authentication ? Explicit (you must provide some login/password independently of your windows account) or implicitly (via kerberos via your AD or anything else)

[theit]

The proxy requires authentication in form of username and password from my domain account. To simplify life I have set up a local Squid proxy instance that just forwards all incoming requests to our company proxy and automatically applies the necessary user credentials. This prevents me from supplying them to each tool/program that needs to access the Internet...

[Eagle3386]

@milipili: regarding your first question: yes, that's correct. N++ goes through the proxy via HTTP(S) and our inhouse-CA when connecting to HTTP(S) outside of our company network.

Regarding your second question: yes, I do know it - and it behaves differently than @theit's (once in a year moment: 👍 @ MS for inventing NTLM-based authentication!), because its implicitly via AD.

[schtritoff]

I think that the problem is in other application since its the GUP.exe that throws this error. Basically curl which is used for update check should be able to pass NTLM auth data to proxy + bundled curl should be updated (to at least version 7.44) to support option 'CURLSSLOPT_NO_REVOKE'.

Someone should open issue and maybe contribute to updater project @ https://github.com/gup4win/wingup (http://wingup.org/) since there this problem should be addressed.

EDIT: curl works with this command (passing windows auth to the proxy): http://stackoverflow.com/a/1277196/1155121

EDIT2: CA store is ok (its using windows CA store), ssl no revoke more details: curl/curl#264

[milipili]

I think that's the thing: --proxy-ntlm. Not sure if the support is compiled for WinGup.

[Eagle3386]

Any progress on this? :)

Maybe #967 and #1826 are related?

[schtritoff]

This issue could be solved in upstream updater project (https://github.com/gup4win/wingup), there is even a pull request for updating CURL library (gup4win/wingup#10) but still not merged from maintainer.
Then, wingup should be tweaked to support:

• CURLSSLOPT_NO_REVOKE curl setting (would fix this issue)
• support NTLM auth for proxy, --proxy-ntlm
• passthrough username and password from windows logged user, -U :

[Bitnugger]

I had that problem too...

Cause: Eset (antivirus)
Solution: Open "Advanced Settings" in Eset,
Edit "SSL/TLS-Filter", Change settings for Notepad++ to "Ignore".

[Eagle3386]

You didn't have the same issue. You just experienced the same result because of a messy HTTPS-interception service caused by extreme (and questionable) firewall routines of Eset.

[donho]

@schtritoff
I have update cURL to the latest version and enable the option CURLSSLOPT_NO_REVOKE :
gup4win/wingup@f3bf515

Is it the fix for this issue? Or there are somethings-else to do?

[donho]

I will build a notepad++ installer with the new updater
Is there anyone here can test it to validate the fix?

[schtritoff]

Please provide test build, I can test it.

[donho]

Thank you @schtritoff !

I have built Notepad++ as v7.5 fo testing to download the curent vesion v7.5.1

32 bits
https://notepad-plus-plus.org/temp/npp.7.5.Installer.4TEST.exe

64 bits:
https://notepad-plus-plus.org/temp/npp.7.5.Installer.4TEST.x64.exe

Anyone wants to join fo testing is welcome!

[schtritoff]

Success! With 7.5 32-bit test version I was able to update to version 7.5.1. My corporate environment have following setup: proxy with NTLM auth (windows credentials pass-through worked - no additional setup required) and custom root CA loaded in Windows Root certificate store for MITM scanning.
Thanks

[donho]

@schtritoff Thank you so much for your test and the validation of this fix, and especially for your solution!
I'll release bioth WinGup and Notepad++ ASAP.

[alexhass]

Using CURLSSLOPT_NO_REVOKE sounds like a serious security issue. There are good reasons to use revocation lists.

[Eagle3386]

The installer is officially signed and downloaded from the official source. That makes at least 2 factors against infiltrators. Besides, N++ lovers have a brain.exe, running version 42.23.1337, when it comes to suspicious programs.

So please, show some alternatives you can come up with for those N++ lovers hidden behind corporate firewalls with DPI and no chance to counter them.

[alexhass]

The question is only why your DPI blocks revocation lists. This is no correct behaviour.

Revocation lists are used more and more for serious reasons. You may remember why the ssl business of startcom and symantec and others will be terminated soon...

[Eagle3386]

The DPI doesn't block revocation lists. You seem to misunderstand the usage of CURLSSLOPT_NO_REVOKE on Windows.
As https://curl.haxx.se/libcurl/c/CURLOPT_SSL_OPTIONS.html clearly states:

with an exception in the case of Windows' Untrusted Publishers blacklist which it seems can't be bypassed

hence it does revoke if found within the Untrusted Publishers blacklist, ignoring any revocation a user or program might try to bypass.

Besides, I requested alternatives on your end for the described scenario in order to provide N++ lovers with updates while being located behind a corporate firewall with DPI and its own company CA certs (hence the warning, not error). Up to now, you failed to do so, but continue to complain about paths chosen. It's easy to beef about something without providing an alternative, though it won't fix the issue and only increase this issue's comments count.