Notepad++ v8.8.3 Release: self-signed certificate

xomx

I also see for the current nppRoot.crt:

Serial number: 63a633d265f1ffed66c5c67cbd9b7189
Thumbprint: c80539ff7076d22e73a01f164108dafbf06e45e4

donho

@sevem47 said in Notepad++ v8.8.3 Release: self-signed certificate:

@PeterJones
This I have seen, but unfortunately this does not match with the current root certificate that can be downloaded:

It should be 63a633d265f1ffed66c5c67cbd9b7189
Fixed in https://notepad-plus-plus.org/resources/

PeterJones

fixed usermanual

SwordReign8

Hello,

It appears that the hash that generates from the nppRoot.crt file does not match the sequence, “443B4543C3A682804540849793556FFD3A6CE5D4721C9ADFDA6450223DDD54D7,” listed within both the Resources heading and the Notepad++ User Manual. I could not find any posts or comments regarding this issue, after combing through the manual, the Notepad++ v8.8.3 Release Candidate topic, and this release topic. The good side is that the serial number and thumbprint are correct when the file is run with the Windows Crypto Shell Extensions app.

PeterJones

@SwordReign8 ,

does not match the sequence, “443B4543C3A682804540849793556FFD3A6CE5D4721C9ADFDA6450223DDD54D7,”

I concur that when I download the .crt from any of the three locations, it gives e133b9302aae0aa7d9f6db63289aeea709fb57346dc702357f9d71b1bd3ffb21, not the value listed in @donho’s posts

I am not convinced that a SHA256 generated from the .crt file is overly useful. Internally, the .crt file is a BASE64-encoded version of the binary certificate data; it doesn’t actually matter whether the newlines are LF-only or CRLF, or whether there is a final newline after the -----END CERTIFICATE----- or not (but those all change the SHA256); the only critical thing is whether when the BASE64 data is decoded that it resolve into the certificate data that matches the thumbprint and signature – which it does. (I am not a security expert; this is just my opinion on the matter.)

@donho: I would recommend that you remove the SHA256 from the /resources/ page and I’ll remove it from the usermanual, to avoid end-user confusion. If you agree, let me know, and I’ll work on removing it on my end; if you disagree, and want to keep publishing the SHA256, could you please re-confirm the value, because the SHA256 that I can calculate does not agree with your published data.

donho

@SwordReign8

It appears that the hash that generates from the nppRoot.crt file does not match the sequence, “443B4543C3A682804540849793556FFD3A6CE5D4721C9ADFDA6450223DDD54D7,” listed within both the Resources heading and the Notepad++ User Manual.

Both fingerprints (SHA1 & SHA254) are correct on the Resources heading and the Notepad++ User Manual.

You can use openssl under Git Bash to verify them:

yyy@XXXXXXX MINGW64 /c/aaaa/bbbb (master)
$ openssl x509 -in /c/abc/nppRoot.crt -noout -fingerprint -sha1
SHA1 Fingerprint=C8:05:39:FF:70:76:D2:2E:73:A0:1F:16:41:08:DA:FB:F0:6E:45:E4

yyy@XXXXXXX MINGW64 /c/aaaa/bbbb (master)
$ openssl x509 -in /c/abc/nppRoot.crt -noout -fingerprint -sha256
SHA256 Fingerprint=44:3B:45:43:C3:A6:82:80:45:40:84:97:93:55:6F:FD:3A:6C:E5:D4:72:1C:9A:DF:DA:64:50:22:3D:DD:54:D7

That said, SHA256 may be removed from the root certificate info, to avoid the users’ confusion, since such info can not be found in certificate opened by Crypto Shell extension of Windows.

What do you think @PeterJones ?

donho

@PeterJones said in Notepad++ v8.8.3 Release: self-signed certificate:

@donho: I would recommend that you remove the SHA256 from the /resources/ page and I’ll remove it from the usermanual, to avoid end-user confusion. If you agree, let me know, and I’ll work on removing it on my end; if you disagree, and want to keep publishing the SHA256, could you please re-confirm the value, because the SHA256 that I can calculate does not agree with your published data.

SHA256 is removed in Resources page.

PeterJones

@donho said in Notepad++ v8.8.3 Release: self-signed certificate:

You can use openssl … to verify them

Right.

I have openssl on Windows, and it can confirm:

C:\Users\pryrt\Downloads>ls -latr nppRoot-primary*.crt
-rw-rw-rw-  1 pryrt 0 6380 2025-07-11 10:07 nppRoot-primary.crt
-rw-rw-rw-  1 pryrt 0 6480 2025-07-11 10:13 nppRoot-primary-crlf.crt

C:\Users\pryrt\Downloads>openssl x509 -in nppRoot-primary.crt -noout -fingerprint -sha256
sha256 Fingerprint=44:3B:45:43:C3:A6:82:80:45:40:84:97:93:55:6F:FD:3A:6C:E5:D4:72:1C:9A:DF:DA:64:50:22:3D:DD:54:D7

C:\Users\pryrt\Downloads>openssl x509 -in nppRoot-primary-crlf.crt -noout -fingerprint -sha256
sha256 Fingerprint=44:3B:45:43:C3:A6:82:80:45:40:84:97:93:55:6F:FD:3A:6C:E5:D4:72:1C:9A:DF:DA:64:50:22:3D:DD:54:D7

That is giving the SHA256 fingerprint of the binary data, not the SHA256 for the BASE64-encoded text file.

What do you think

Since the MS Windows certificate viewer (Crypto Shell extension) doesn’t show the SHA256 fingerprint, and the since an external tool (like Notepad++ > Tools > SHA-256 > Generate from files) will show the SHA256 of the bytes of the file they downloaded, not the hash of the underlying encoded binary data, the user would get something like

cce7717c8a38afec9e6de523d108cdd3615a3e1543aeb6e31663b6b7dbc19c90  nppRoot-primary-crlf.crt
e133b9302aae0aa7d9f6db63289aeea709fb57346dc702357f9d71b1bd3ffb21  nppRoot-primary.crt

depending on whether their copy of the file has CRLF (first) or just LF as originally published (second) – and neither of those match the hash of the internal binary data.

That causes user confusion, which is bad (and may lead them to incorrectly conclude there is a problem with the file).

SHA256 is removed in Resources page.

Thanks. It will be removed from the User Manual soon.

datatraveller1

BTW (just for information), VirusTotal has an “invalid-signature” tag at
https://www.virustotal.com/gui/file/7094a07167648628e47249a16d9d6db922e5aa1255ac4322a2e4900d233372dd?nocache=1
Ah sorry, I have just read this is normal for self-signed certificates.

donho

FYI, auto-updater has been triggered to v8.8.3.