RE: SHA256 openssl-1.1.1i Checksum Error

[Michael Wojcik]

> From: openssl-users  On Behalf Of Dr. 
> Matthias St. Pierre
> Sent: Monday, 28 December, 2020 11:50

> I have no experience with zsh, but it seems that quoting is handled
> differently by zsh?

Is the problem that quoting is handled differently, or that he actually had 
Unicode left-double-quote and right-double-quote characters there rather than 
proper ASCII double-quote characters? That's how it appears in the message as I 
received it.

> At least it looks like the double quotes ended up in the GET line

Agreed.

> and you simply received an HTTP 404 Not Found (which is the reason why your
> digest isn’t correct.)

Agreed.

I'll add: Don't check the checksum. Check the signature:

1. Install an OpenPGP implementation such as gpg, if you don't already have 
one. (One may come with macOS; I have no idea.)

2. Download the .asc file corresponding to the tarball you downloaded.

3. Check the signature. With gpg2, for example:

   $ gpg2 --verify openssl-1.1.1i.tar.gz.asc openssl-1.1.1i.tar.gz
   gpg: Signature made 12/08/20 06:21:06 MST using RSA key ID 0E604491

Now, you presumably won't have the signing public key (for 1.1.1i that's a key 
owned by Matt Caswell) in your keyring. You can download it from a public 
keyserver and mark it as trusted, so you'll also get verification that the 
signature was generated with the correct key:

   gpg: Good signature from "Matt Caswell " [full]
   gpg: aka "Matt Caswell " [full]

While checking the signature runs into all the well-documented issues with the 
PGP Web of Trust, it's still stronger (in the sense that it prunes more of the 
attack tree, under sensible threat models) than just checking the hash. And 
once you're set up to do it, it's a simpler operation for future downloads.

--
Michael Wojcik

RE: openssl-users Digest, Vol 73, Issue 29

[Michael Wojcik]

> From: openssl-users  On Behalf Of Jochen
> Bern
> Sent: Friday, 25 December, 2020 03:37

I believe David von Oheimb has already provided a solution for the original 
problem in this thread (setting subjectKeyIdentifier and authorityKeyIdentifer 
lets OpenSSL pick the right certificate from the trust-anchor collection). I 
wanted to comment on this tangential point:

> For server
> certs, where you need the CN to match the FQDN, you might want to add an
> OU with a timestamp so as to have the *DN* as a whole differ ...

If your entity certificate is X.509v3 and the client complies with RFC 5280, 
the CN of the Subject DN shouldn't matter, as long as the server name *as 
expected by the peer* appears in a subjectAlternativeName extension.

That is, if the client wants to connect to "www.foo.com", the server's 
certificate should have a DNS-type sAN with the value "www.foo.com". If the 
client wants to connect to the unqualified hostname "foo", the server's 
certificate should have a DNS-type sAN with the value "foo". If the client 
wants to connect to "192.168.2.1", the server's certificate should have an 
IPADR-type sAN with that value. And so on. If any sANs are present, the CN (if 
any) of the Subject DN should be ignored.

Here "wants to connect" is defined by the application and/or its TLS 
implementation. The implementation may provide a way for a client to specify 
the subject-name it wants to find in the entity certificate, or it may simply 
take whatever hostname or IP address string it's asked to connect to, and use 
that.

Also remember that OpenSSL prior to 1.0.2 didn't have support for checking 
hostnames at all. With 1.0.2 you have to make some non-obvious calls to set the 
expected name, and with 1.1.0 and later you need to use SSL_set1_host (or the 
1.0.2 method); there's a page on the OpenSSL wiki for this. I don't remember if 
this has changed again in 3.0.

--
Michael Wojcik

RE: openssl-users Digest, Vol 73, Issue 29

[Michael Wojcik]

> From: openssl-users  On Behalf Of Jochen
> Bern
> Sent: Friday, 25 December, 2020 03:37

I believe David von Oheimb has already provided a solution for the original 
problem in this thread (setting subjectKeyIdentifier and authorityKeyIdentifer 
lets OpenSSL pick the right certificate from the trust-anchor collection). I 
wanted to comment on this tangential point:

> For server
> certs, where you need the CN to match the FQDN, you might want to add an
> OU with a timestamp so as to have the *DN* as a whole differ ...

If your entity certificate is X.509v3 and the client complies with RFC 5280, 
the CN of the Subject DN shouldn't matter, as long as the server name *as 
expected by the peer* appears in a subjectAlternativeName extension.

That is, if the client wants to connect to "www.foo.com", the server's 
certificate should have a DNS-type sAN with the value "www.foo.com". If the 
client wants to connect to the unqualified hostname "foo", the server's 
certificate should have a DNS-type sAN with the value "foo". If the client 
wants to connect to "192.168.2.1", the server's certificate should have an 
IPADR-type sAN with that value. And so on. If any sANs are present, the CN (if 
any) of the Subject DN should be ignored.

Here "wants to connect" is defined by the application and/or its TLS 
implementation. The implementation may provide a way for a client to specify 
the subject-name it wants to find in the entity certificate, or it may simply 
take whatever hostname or IP address string it's asked to connect to, and use 
that.

Also remember that OpenSSL prior to 1.0.2 didn't have support for checking 
hostnames at all. With 1.0.2 you have to make some non-obvious calls to set the 
expected name, and with 1.1.0 and later you need to use SSL_set1_host (or the 
1.0.2 method); there's a page on the OpenSSL wiki for this. I don't remember if 
this has changed again in 3.0.

--
Michael Wojcik

Re: Format error in certificate´s notAfter field

[Thomas Dwyer III]

This certificate is not the same one causing the error message in your
original email. The error message you provided earlier included
"serial=17702460327850242852" (or f5:ab:c5:e0:63:f5:73:24 in hex) but the
certificate you provided here has serial=16005263760024127372
(de:1e:1e:97:18:ab:c7:8c).


Tom.III


On Sun, Dec 27, 2020 at 11:50 PM Raúl Uría Elices  wrote:

> Here it is:
>
> -BEGIN CERTIFICATE-
> MIIESjCCA7OgAwIBAgIJAN4eHpcYq8eMMA0GCSqGSIb3DQEBCwUAMIGjMQswCQYD
> VQQGEwJlczEVMBMGA1UEBxMMUGVuYWNhc3RpbGxvMSYwJAYDVQQKEx1OT1JCRVJU
> IERFTlRSRVNTQU5HTEUgR0VSUE9TQTEyMDAGA1UEAxMpTk9SQkVSVCBERU5UUkVT
> U0FOR0xFIEdFUlBPU0EgV2ViQWRtaW4gQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWlu
> QGFzdGFyby5sb2NhbDAeFw0xNzA5MDgxNTQ0NTJaFw0zNjA3MTgxNTEyMThaMGsx
> CzAJBgNVBAYTAmVzMRUwEwYDVQQHDAxQZW5hY2FzdGlsbG8xJjAkBgNVBAoMHU5P
> UkJFUlQgREVOVFJFU1NBTkdMRSBHRVJQT1NBMR0wGwYDVQQDDBRhc2cyMjAuZ2Vy
> cG9zYS5sb2NhbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAN+gNXRC
> WtsP9LANPgFJ1vj1/6naVUiHBq+AKgPePwOK6qbUczG+E8Zh8xr/JpcCjdrTLZNF
> rllVoEodthSvKnlaMI7qIgDWQE3MtVot5ARAZHFMob2uy3zeZ/uJniheYmj7BNy2
> d6pkFzlZyPiNh65KIBbEuZEKAgKQwRAduYWk+689p2Jnujj13yodpOuGPSjr9inz
> qLTK1GIkTf51O6GMGiu5erj27LHKAJojAVSjMDJ1AeDAsNg+RLLDP/q+Fi0wLUwL
> MPq2rhiXZvVPjU/iukiwrzNHqwZTIwpayNatjoskKE/KS+ldEIhMlythOiPVWgYs
> zAUdD1G3HL4cQgECAwEAAaOCATcwggEzMB0GA1UdDgQWBBQqUYZktt2XccSH1Sp2
> g8y8zwZ3nzCB2AYDVR0jBIHQMIHNgBSXppMhHL+r08UaJqK9kW36GvpusaGBqaSB
> pjCBozELMAkGA1UEBhMCZXMxFTATBgNVBAcTDFBlbmFjYXN0aWxsbzEmMCQGA1UE
> ChMdTk9SQkVSVCBERU5UUkVTU0FOR0xFIEdFUlBPU0ExMjAwBgNVBAMTKU5PUkJF
> UlQgREVOVFJFU1NBTkdMRSBHRVJQT1NBIFdlYkFkbWluIENBMSEwHwYJKoZIhvcN
> AQkBFhJhZG1pbkBhc3Rhcm8ubG9jYWyCCQDeHh6XGKvHijAfBgNVHREEGDAWghRh
> c2cyMjAuZ2VycG9zYS5sb2NhbDAJBgNVHRMEAjAAMAsGA1UdDwQEAwIF4DANBgkq
> hkiG9w0BAQsFAAOBgQAqsvoAFxWEWSxZHtEgDHEBfflBJEm3QqAl8bMb3O4rOnIV
> ufq/dkAx6AYzmtFZhWMIJnh4ZTU8ULjuAkqC2yXEBktpSR9VQFKabToLSuAW9QC7
> Db2ELKw8kXQgFxS0nkDhEgAitukcJ8TuVq7hlvRVwC6vnRRdKYaaT5cERZbDOg==
> -END CERTIFICATE-
>
>
>
>

RE: SHA256 openssl-1.1.1i Checksum Error

[Dr. Matthias St. Pierre]

I have no experience with zsh, but it seems that quoting is handled differently 
by zsh?
At least it looks like the double quotes ended up in the GET line and you 
simply received
an HTTP 404 Not Found (which is the reason why your digest isn’t correct.)

HTH,
Matthias


> GET /source/openssl-“1.1.1i”.tar.gz HTTP/1.1
> Host: www.openssl.org
> User-Agent: curl/7.64.1
> Accept: */*
>
  0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0< 
HTTP/1.1 404 Not Found


smime.p7s
Description: S/MIME cryptographic signature

SHA256 openssl-1.1.1i Checksum Error

[Chris Outwin]

This is my first post.  OpenSSL is not my forte.

The code below returns an unexpected checksum value for openssl-1.1.1i..  
Strangely, when the same code is run for a previous version, the correct 
checksum value is returned.   Here is what I’ve tried:

1.  Downloaded the current SHA256 value for openssl-1.1.1i.tar.gz from 
https://www.openssl.org/source/
2.  Included that checksum value in the code below
3.  Run the code in macOS Version10.15.7’s Terminal app (using bash)
4.  Observed that the checksum value does not match the downloaded value in 
Step 1 above

Here is the part of the script associated with the problem.  Notice an 
incorrect checksum of 
c413e17d876098e89478c85e1d2b96db79bcdc943ad54550f0351da4f141ec5e is returned at 
the end.  What am I doing wrong? 

#!/bin/zsh
# This script builds OpenSSL libssl and libcrypto for 64-bit devices.
# Binary distribution for ios64-cross-arm64 and ios64-cross-arm64e

VERSION=“1.1.1i”
VERSION_SHA256_CHECKSUM="e8be6a35fe41d10603c3cc635e93289ed00bf34b79671a3a4de64fcee00d5242"

##
curl -Ov https://www.openssl.org/source/openssl-$VERSION.tar.gz

# Checksum to verify OpenSSL files are not corrupted.
FILE_CHECKSUM=$(shasum -a 256 openssl-$VERSION.tar.gz | awk '{print $1; exit}')
if [ "$FILE_CHECKSUM" != "$VERSION_SHA256_CHECKSUM" ]; then
echo "OpenSSL version $VERSION failed checksum."
echo "Checksum should be:" $VERSION_SHA256_CHECKSUM
echo "Actual downloaded file checksum:" $FILE_CHECKSUM
exit 1
fi

Here is the verbose listing returned by the script:

chrisoutwin@Chriss-iMac OpenSSL % bash build.sh
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
  0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0* 
  Trying 23.2.168.18...
* TCP_NODELAY set
* Connected to www.openssl.org (23.2.168.18) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/cert.pem
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
} [229 bytes data]
* TLSv1.2 (IN), TLS handshake, Server hello (2):
{ [108 bytes data]
* TLSv1.2 (IN), TLS handshake, Certificate (11):
{ [2556 bytes data]
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
{ [333 bytes data]
* TLSv1.2 (IN), TLS handshake, Server finished (14):
{ [4 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
} [70 bytes data]
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
} [1 bytes data]
* TLSv1.2 (OUT), TLS handshake, Finished (20):
} [16 bytes data]
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
{ [1 bytes data]
* TLSv1.2 (IN), TLS handshake, Finished (20):
{ [16 bytes data]
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
*  subject: CN=www.openssl.org
*  start date: Oct 30 19:31:03 2020 GMT
*  expire date: Jan 28 19:31:03 2021 GMT
*  subjectAltName: host "www.openssl.org" matched cert's "www.openssl.org"
*  issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
*  SSL certificate verify ok.
> GET /source/openssl-“1.1.1i”.tar.gz HTTP/1.1
> Host: www.openssl.org
> User-Agent: curl/7.64.1
> Accept: */*
> 
  0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0< 
HTTP/1.1 404 Not Found
< Server: Apache/2.4.29 (Ubuntu)
< Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
< Accept-Ranges: bytes
< Content-Type: text/html; charset=UTF-8
< Content-Length: 4182
< Cache-Control: max-age=172800
< Expires: Wed, 30 Dec 2020 15:20:43 GMT
< Date: Mon, 28 Dec 2020 15:20:43 GMT
< Connection: keep-alive
< 
{ [1536 bytes data]
100  4182  100  41820 0   5873  0 --:--:-- --:--:-- --:--:--  5873
* Connection #0 to host www.openssl.org left intact
* Closing connection 0
OpenSSL version “1.1.1i” failed checksum.
Checksum should be: 
e8be6a35fe41d10603c3cc635e93289ed00bf34b79671a3a4de64fcee00d5242
Actual downloaded file checksum: 
c413e17d876098e89478c85e1d2b96db79bcdc943ad54550f0351da4f141ec5e