I have a Debian 10 buster server, one of several identical hardware/software configs. I use a script that deploys them, they are all identical. However, one of them is throwing an error when using wget:
# wget https://mirrors.edge.kernel.org/pub/linux/kernel/v5.x/linux-5.6.15.tar.xz
--2020-05-30 12:49:20-- https://mirrors.edge.kernel.org/pub/linux/kernel/v5.x/linux-5.6.15.tar.xz
Resolving mirrors.edge.kernel.org (mirrors.edge.kernel.org)... 147.75.69.165, 2604:1380:1000:8100::1
Connecting to mirrors.edge.kernel.org (mirrors.edge.kernel.org)|147.75.69.165|:443... connected.
ERROR: The certificate of ‘mirrors.edge.kernel.org’ is not trusted.
ERROR: The certificate of ‘mirrors.edge.kernel.org’ has expired.
Things I've done:
Checked that the SSL certificate is valid
Confirmed the exact same command works on other servers
Checked the system date, confirmed correct
Checked resolv.conf, configuring for 8.8.8.8 8.8.4.4 identical to others
Checked name resolution manually, working fine
Reinstall apt-get install --reinstall ca-certificates
Ran update-ca-certificates --fresh
Ran c_rehash
Used curl, it works fine without errors, shows correct SSL expiration
The problem seems to only be wget from what I can tell. I don't need a workaround. I need a solution so I have confidence this server is operating as it should.
I have the same symptom for f-droid.org:
% wget 'https://f-droid.org/F-Droid.apk'
--2020-06-03 14:10:18-- https://f-droid.org/F-Droid.apk
Resolving f-droid.org (f-droid.org)... 217.160.165.113, 148.251.140.42
Connecting to f-droid.org (f-droid.org)|217.160.165.113|:443... connected.
ERROR: The certificate of ‘f-droid.org’ is not trusted.
ERROR: The certificate of ‘f-droid.org’ has expired.
In my case (Debian 9 stretch), curl doesn't work either:
% curl 'https://f-droid.org/F-Droid.apk'
curl: (60) SSL certificate problem: certificate has expired
More details here: https://curl.haxx.se/docs/sslcerts.html
Looking at wget source one can see the error comes from status flag returned by gnutls_certificate_verify_peers2. We can ask gnutls to show certificate verification details:
% gnutls-cli f-droid.org -p 443
Processed 151 CA certificate(s).
Resolving 'f-droid.org:443'...
Connecting to '217.160.165.113:443'...
- Certificate type: X.509
- Got a certificate list of 3 certificates.
- Certificate[0] info:
- subject `CN=f-droid.org,OU=PositiveSSL,OU=Domain Control Validated', issuer `CN=Sectigo RSA Domain Validation Secure Server CA,O=Sectigo Limited,L=Salford,ST=Greater Manchester,C=GB', serial 0x02a8508e042b9f065fafadd87cd7d103, RSA key 2048 bits, signed using RSA-SHA256, activated `2019-09-17 00:00:00 UTC', expires `2020-09-16 23:59:59 UTC', key-ID `sha256:e97ccbf3c188b5cf69a83ed0fc39b001ce1688a62b573193cef3f74984c7d703'
Public Key ID:
sha1:638f93856e1f5edfcbd40c46d4160cff21b0713a
sha256:e97ccbf3c188b5cf69a83ed0fc39b001ce1688a62b573193cef3f74984c7d703
Public key's random art:
+--[ RSA 2048]----+
| o o+o.|
| *...o|
| E ..+ |
| . ... o|
| S . o .|
| o * . o.|
| * o . .o|
| . + o .o. |
| o .oo|
+-----------------+
- Certificate[1] info:
- subject `CN=Sectigo RSA Domain Validation Secure Server CA,O=Sectigo Limited,L=Salford,ST=Greater Manchester,C=GB', issuer `CN=USERTrust RSA Certification Authority,O=The USERTRUST Network,L=Jersey City,ST=New Jersey,C=US', serial 0x7d5b5126b476ba11db74160bbc530da7, RSA key 2048 bits, signed using RSA-SHA384, activated `2018-11-02 00:00:00 UTC', expires `2030-12-31 23:59:59 UTC', key-ID `sha256:e1ae9c3de848ece1ba72e0d991ae4d0d9ec547c6bad1dddab9d6beb0a7e0e0d8'
- Certificate[2] info:
- subject `CN=USERTrust RSA Certification Authority,O=The USERTRUST Network,L=Jersey City,ST=New Jersey,C=US', issuer `CN=AddTrust External CA Root,OU=AddTrust External TTP Network,O=AddTrust AB,C=SE', serial 0x13ea28705bf4eced0c36630980614336, RSA key 4096 bits, signed using RSA-SHA384, activated `2000-05-30 10:48:38 UTC', expires `2020-05-30 10:48:38 UTC', key-ID `sha256:c784333d20bcd742b9fdc3236f4e509b8937070e73067e254dd3bf9c45bf4dde'
- Status: The certificate is NOT trusted. The certificate chain uses expired certificate.
*** PKI verification of server certificate failed...
So the problem is the USERTrust RSA Certification Authority certificate supplied by the server f-droid.org. This is an intermediate cert signed by AddTrust External CA Root that expired 4 days ago.
The Debian ca-certificates package has a self-signed (root) certificate for USERTrust RSA Certification Authority:
% openssl x509 -inform PEM -in /usr/share/ca-certificates/mozilla/USERTrust_RSA_Certification_Authority.crt -text | grep -A2 Validity
Validity
Not Before: Feb 1 00:00:00 2010 GMT
Not After : Jan 18 23:59:59 2038 GMT
...but gnutls is confused by the expired cert supplied by the server, hence the error.
In your case (mirrors.edge.kernel.org) the certificate chain is as follows:
% gnutls-cli mirrors.edge.kernel.org -p 443
Processed 151 CA certificate(s).
Resolving 'mirrors.edge.kernel.org:443'...
Connecting to '147.75.101.1:443'...
- Certificate type: X.509
- Got a certificate list of 3 certificates.
- Certificate[0] info:
- subject `CN=*.edge.kernel.org', issuer `CN=Sectigo RSA Domain Validation Secure Server CA,O=Sectigo Limited,L=Salford,ST=Greater Manchester,C=GB', serial 0x00a34d0ccfbf4ea450fe030fd3378f5d68, RSA key 2048 bits, signed using RSA-SHA256, activated `2020-03-16 00:00:00 UTC', expires `2021-03-16 23:59:59 UTC', key-ID `sha256:f3746cf281b6453def23289054e75e26e157bfd9eed5252b76ffdc828b802e41'
Public Key ID:
sha1:72d8fc84d0dea848189bc3ff8eb1d47629fd72c0
sha256:f3746cf281b6453def23289054e75e26e157bfd9eed5252b76ffdc828b802e41
Public key's random art:
+--[ RSA 2048]----+
| |
| . |
| . . . |
| . = * + |
| * . o.S o |
| + o =E+ |
| = = +.. |
| . * o... |
| o.o o. |
+-----------------+
- Certificate[1] info:
- subject `CN=Sectigo RSA Domain Validation Secure Server CA,O=Sectigo Limited,L=Salford,ST=Greater Manchester,C=GB', issuer `CN=USERTrust RSA Certification Authority,O=The USERTRUST Network,L=Jersey City,ST=New Jersey,C=US', serial 0x7d5b5126b476ba11db74160bbc530da7, RSA key 2048 bits, signed using RSA-SHA384, activated `2018-11-02 00:00:00 UTC', expires `2030-12-31 23:59:59 UTC', key-ID `sha256:e1ae9c3de848ece1ba72e0d991ae4d0d9ec547c6bad1dddab9d6beb0a7e0e0d8'
- Certificate[2] info:
- subject `CN=USERTrust RSA Certification Authority,O=The USERTRUST Network,L=Jersey City,ST=New Jersey,C=US', issuer `CN=USERTrust RSA Certification Authority,O=The USERTRUST Network,L=Jersey City,ST=New Jersey,C=US', serial 0x01fd6d30fca3ca51a81bbc640e35032d, RSA key 4096 bits, signed using RSA-SHA384, activated `2010-02-01 00:00:00 UTC', expires `2038-01-18 23:59:59 UTC', key-ID `sha256:c784333d20bcd742b9fdc3236f4e509b8937070e73067e254dd3bf9c45bf4dde'
- Status: The certificate is trusted.
Again we see USERTrust RSA Certification Authority, but here it's a self-signed (root) certificate, not expired. I guess kernel.org did supply expired intermediate certificate too, but corrected under your hands. I think --no-dns-cache is irrelevant, mere coincidence.
Incidentally, Firefox displays https://f-droid.org just fine. Show page info / Security reveals new self-signed (root) USERTrust cert: Not after: 18 January 2038, 23:59:59 GMT. That is, Firefox ignored the expired intermediate USERTrust cert supplied by the server, used the valid root USERTrust cert available locally.
Resolution? The server webmaster should remove the obsolete intermediate certificate from the server configuration. In the meantime, use Firefox (or curl, if it works) instead of wget.
Update: as f-droid people pointed out, the gnutls bug is fixed already, the fix should be in Debian-security soon.
My problem was with the Let's Encrypt cert, it said the same, on Debian 8.
My solution:
With the gnutls-cli command above I was able to look into the whole chain and it gave me a little more information, which eventually led me here: https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/
With this information I issued
# dpkg-reconfigure ca-certificates
Unselected the already expired DST Root CA X3
And it started to work.
I was able to solve my own problem using --no-dns-cache
# wget --no-dns-cache --debug https://mirrors.edge.kernel.org/pub/linux/kernel/v5.x/linux-5.6.15.tar.xz
After this, it apparently updated whatever file was broken. It now works without the --no-dns-cache as well. So strange, but it seems stable.
I'm switching my CI process from producing APK files to App Bundles. One stage in my pipeline will, after producing the signed binary, dump the signature and validate the signature on the APK to make sure it's signed properly before continuing.
> apksigner verify --print-certs my-signed-binary.apk
Signer #1 certificate DN: CN=<NAME>, OU=<GROUP>, O=<COMPANY>, L=<CITY>, ST=<STATE>, C=<COUNTRY>
Signer #1 certificate SHA-256 digest: <DIGEST1>
Signer #1 certificate SHA-1 digest: <DIGEST2>
Signer #1 certificate MD5 digest: <DIGEST3>
Is there an equivalent to dump the signature on the overall App Bundle once it's been produced?
I tried using jarsigner, but ended up with hundreds of lines of output.
> jarsigner -verbose -verify -certs my-signed-binary.aab
...
smk 12 Wed Dec 31 16:00:00 PST 1969 base/assets.pb
>>> Signer
X.509, CN=<NAME>, OU=<GROUP>, O=<ORGANIZATION>, L=<CITY>, ST=<STATE>, C=<COUNTRY> (myapp)
[certificate is valid from 5/31/13 1:27 PM to 10/16/40 1:27 PM]
smk 85 Wed Dec 31 16:00:00 PST 1969 base/native.pb
>>> Signer
X.509, CN=<NAME>, OU=<GROUP>, O=<ORGANIZATION>, L=<CITY>, ST=<STATE>, C=<COUNTRY> (myapp)
[certificate is valid from 5/31/13 1:27 PM to 10/16/40 1:27 PM]
smk 2075002 Wed Dec 31 16:00:00 PST 1969 base/resources.pb
>>> Signer
X.509, CN=<NAME>, OU=<GROUP>, O=<ORGANIZATION>, L=<CITY>, ST=<STATE>, C=<COUNTRY> (myapp)
[certificate is valid from 5/31/13 1:27 PM to 10/16/40 1:27 PM]
542451 Tue Jan 01 00:00:00 PST 1980 META-INF/MYAPP.SF
1390 Tue Jan 01 00:00:00 PST 1980 META-INF/MYAPP.RSA
s k 542352 Tue Jan 01 00:00:00 PST 1980 META-INF/MANIFEST.MF
>>> Signer
X.509, CN=<NAME>, OU=<GROUP>, O=<ORGANIZATION>, L=<CITY>, ST=<STATE>, C=<COUNTRY> (myapp)
[certificate is valid from 5/31/13 1:27 PM to 10/16/40 1:27 PM]
s = signature was verified
m = entry is listed in manifest
k = at least one certificate was found in keystore
i = at least one certificate was found in identity scope
- Signed by "CN=<NAME>, OU=<GROUP>, O=<ORGANIZATION>, L=<CITY>, ST=<STATE>, C=<COUNTRY>"
Digest algorithm: SHA-256
Signature algorithm: SHA256withRSA, 2048-bit key
jar verified.
Is the very last part of this ("Signed by...") the signature of the overall App Bundle? Is there an easier way to get the signature of the App Bundle than hacking this output with sed?
I used keytool and I think it produces correct results
keytool -printcert -jarfile my-signed-binary.aab
In SSL how does it check whether there is a matching certificate in the trust-store? Is it by matching the fingerprint or the serial number?
I always thought it's by matching the fingerprint, but when I ran a java SSL debug following is what I got, and I couldn't see any fingerprint there.
*** Certificate chain
chain [0] = [
[
Version: V3
Subject: CN=XXXX
Signature Algorithm: SHA256withRSA, OID = 1.2.840.113549.1.1.11
Key: Sun RSA public key, 1024 bits
modulus: XXXX
public exponent: XXXX
Validity: [From: Mon Mar 16 22:48:10 UTC 2015,
To: Sun Jun 14 22:48:10 UTC 2015]
Issuer: CN=XXXX
SerialNumber: [ XXXXXXX]
Certificate Extensions: 1
[1]: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
...
]
]
]
Algorithm: [SHA256withRSA]
Signature:
...
]
***
I hope this is not a duplicate question (I checked the suggested questions before posting).
It doesn't check whether there is a matching certificate. It checks whether there is a certificate whose subject equals the issuer of this certificate, and whose public key verifies the signature of this certificate.
Quite often, the Certificate Authority Key Identifier is marked as non-critical when present in the certificate to verify, and it's not even always present. You couldn't really rely on that as a fingerprint reference to use.
The verification is done by building a certification path, by chaining the Issuer DN (Distinguished Name) of the certificate to verify to the Subject DN of a CA certificate you trust.
This is described in the CertPathBuilder/CertPathValidator sections of the Java PKI Programmer's Guide. (More generally, this follows RFC 3820, since there are other attributes to check too.)
Alternatively, you can also have an exact End Entity Certificate (not a CA certificate) directly in the truststore. In this case, an exact match with the certificate can be used.
I have been attemping to code sign a dll using a code signing certiticate I have purchased from Comodo. The intention for the signing is to be verifiable via the kernel signing policy. However, in the the EventLog explaining that there are CodeIntegrity errors relating to per-page image hashes not being able to be found.
Below is a summary I what I am doing, if you could please provide advice on where I have gone wrong, or where to look next that would be greatly appreciated.
I have signed a previously signed dll for the sake of testing using the following commands, the result is the same if I used a newly built dll.
"C:\WinDDK\7600.16385.1\bin\amd64\SignTool.exe" sign /v /ph /ac "addtrustexternalcaroot_kmod.crt" /f css-certificate.pfx /p <password> /t http://timestamp.verisign.com/scripts/timstamp.dll VBoxVRDP.dll
The output is as follows
The following certificate was selected:
Issued to: S4 Technology
Issued by: COMODO RSA Code Signing CA
Expires: Wed Nov 11 15:59:59 2015
SHA1 hash: 0161DC2D8757B886E626B25B1770C72B789BAF02
Cross certificate chain (using machine store):
Issued to: Microsoft Code Verification Root
Issued by: Microsoft Code Verification Root
Expires: Sat Nov 01 05:54:03 2025
SHA1 hash: 8FBE4D070EF8AB1BCCAF2A9D5CCAE7282A2C66B3
Issued to: AddTrust External CA Root
Issued by: Microsoft Code Verification Root
Expires: Tue Aug 15 12:36:30 2023
SHA1 hash: A75AC657AA7A4CDFE5F9DE393E69EFCAB659D250
Issued to: COMODO RSA Certification Authority
Issued by: AddTrust External CA Root
Expires: Sat May 30 02:48:38 2020
SHA1 hash: F5AD0BCC1AD56CD150725B1C866C30AD92EF21B0
Issued to: COMODO RSA Code Signing CA
Issued by: COMODO RSA Certification Authority
Expires: Mon May 08 15:59:59 2028
SHA1 hash: B69E752BBE88B4458200A7C0F4F5B3CCE6F35B47
Issued to: S4 Technology
Issued by: COMODO RSA Code Signing CA
Expires: Wed Nov 11 15:59:59 2015
SHA1 hash: 0161DC2D8757B886E626B25B1770C72B789BAF02
Done Adding Additional Store
Successfully signed and timestamped: VBoxVRDP.dll
Number of files successfully Signed: 1
Number of warnings: 0
Number of errors: 0
I now validate the signing using the following command
"C:\WinDDK\7600.16385.1\bin\amd64\SignTool.exe" verify /v /ph /kp VBoxVRDP.dll
The output is as follows
Verifying: VBoxVRDP.dll
Hash of file (sha1): 41909BD87A05CF3E61BBEF7B9DD4C4A8B6E4B2A1
Signing Certificate Chain:
Issued to: AddTrust External CA Root
Issued by: AddTrust External CA Root
Expires: Sat May 30 02:48:38 2020
SHA1 hash: 02FAF3E291435468607857694DF5E45B68851868
Issued to: COMODO RSA Certification Authority
Issued by: AddTrust External CA Root
Expires: Sat May 30 02:48:38 2020
SHA1 hash: F5AD0BCC1AD56CD150725B1C866C30AD92EF21B0
Issued to: COMODO RSA Code Signing CA
Issued by: COMODO RSA Certification Authority
Expires: Mon May 08 15:59:59 2028
SHA1 hash: B69E752BBE88B4458200A7C0F4F5B3CCE6F35B47
Issued to: S4 Technology
Issued by: COMODO RSA Code Signing CA
Expires: Wed Nov 11 15:59:59 2015
SHA1 hash: 0161DC2D8757B886E626B25B1770C72B789BAF02
The signature is timestamped: Mon Dec 15 10:05:37 2014
Timestamp Verified by:
Issued to: Thawte Timestamping CA
Issued by: Thawte Timestamping CA
Expires: Thu Dec 31 15:59:59 2020
SHA1 hash: BE36A4562FB2EE05DBB3D32323ADF445084ED656
Issued to: Symantec Time Stamping Services CA - G2
Issued by: Thawte Timestamping CA
Expires: Wed Dec 30 15:59:59 2020
SHA1 hash: 6C07453FFDDA08B83707C09B82FB3D15F35336B1
Issued to: Symantec Time Stamping Services Signer - G4
Issued by: Symantec Time Stamping Services CA - G2
Expires: Tue Dec 29 15:59:59 2020
SHA1 hash: 65439929B67973EB192D6FF243E6767ADF0834E4
Cross Certificate Chain:
Issued to: Microsoft Code Verification Root
Issued by: Microsoft Code Verification Root
Expires: Sat Nov 01 05:54:03 2025
SHA1 hash: 8FBE4D070EF8AB1BCCAF2A9D5CCAE7282A2C66B3
Issued to: AddTrust External CA Root
Issued by: Microsoft Code Verification Root
Expires: Tue Aug 15 12:36:30 2023
SHA1 hash: A75AC657AA7A4CDFE5F9DE393E69EFCAB659D250
Issued to: COMODO RSA Certification Authority
Issued by: AddTrust External CA Root
Expires: Sat May 30 02:48:38 2020
SHA1 hash: F5AD0BCC1AD56CD150725B1C866C30AD92EF21B0
Issued to: COMODO RSA Code Signing CA
Issued by: COMODO RSA Certification Authority
Expires: Mon May 08 15:59:59 2028
SHA1 hash: B69E752BBE88B4458200A7C0F4F5B3CCE6F35B47
Issued to: S4 Technology
Issued by: COMODO RSA Code Signing CA
Expires: Wed Nov 11 15:59:59 2015
SHA1 hash: 0161DC2D8757B886E626B25B1770C72B789BAF02
Embedded page hashes:
0x00000000 7B54C3ABC3FC7DA85CB40074D653DFB36DF8E0F9
<...>
0x00071a00 0000000000000000000000000000000000000000
Successfully verified: VBoxVRDP.dll
Number of files successfully Verified: 1
Number of warnings: 0
Number of errors: 0
So it all looks good, however, I have noted when looking at the properties of dll via Explorer, but I end up with a CodeIntegrity errors in the EventLog.
Code Integrity is unable to verify the image integrity of the file <...>\VBoxVRDP.dll because the set of per-page image hashes could not be found on the system.
When I look at the Verbose logs of CodeIntegrity I see the following Verbose events
Code Integrity started validating page hashes of <...>\VBoxVRDP.dll file.
Code Integrity completed validating page hashes. Status 0xc0000428.
From what I can tell 0xc0000428 is Windows cannot verify the digital signature of this file, which seems to imply I am missing something somewhere, but I for the life of me cannot figure out exactly what it is I need to do.
Windows support for SHA2 on Win 7 seems to be problematic at present. https://technet.microsoft.com/en-us/library/security/2949927.aspx
There is a fix but note "Revision V2.0 (October 17, 2014): Removed Download Center links for Microsoft security update 2949927. Microsoft recommends that customers experiencing issues uninstall this update. Microsoft is investigating behavior associated with this update, and will update the advisory when more information becomes available."
When run keytool on a .RSA file for an Android APK I see the following:
Serial number: 4a9c4610
Valid from: Mon Aug 31 14:52:16 PDT 2009 until: Sun Sep 25 14:52:16 PDT 2050
Certificate fingerprints:
MD5: 3F:AD:02:4F:2D:CB:E3:EE:69:3C:96:F3:50:F8:E3:76
SHA1: 8A:3C:4B:26:2D:72:1A:CD:49:A4:BF:97:D5:21:31:99:C8:6F:A2:B9
Signature algorithm name: MD5withRSA
Version: 1
Why does it show both SHA1 and MD5 fingerprints even though the algorithm name seems to suggest MD5?
If the question is better answered by me reading some introductory article on this topic, feel free to point me to it.
The fingerprint is simply a hash of parts of the certificate data. It's not related to the hash used in the signature mechanism, so it doesn't have to be MD5.