Revisions to openssl claims to use /private/etc/ssl, but appears not to, What The Heck?

deleted 120 characters in body; edited tags

Source Link

edited Jan 29, 2020 at 6:30

nohillside ♦

104.5k
42
222
275

edit1, fixed "rescued" test case that specifies -CApath;

edit2, fix the markdown that I broke in edit1

I'd love to understand what's going on.

Thanks!

edit1, fixed "rescued" test case that specifies -CApath;

edit2, fix the markdown that I broke in edit1

I'd love to understand what's going on.

Thanks!

I'd love to understand what's going on.

added 60 characters in body

Source Link

edited Jan 28, 2020 at 23:29

hartzell

11
3

[edit, fixed "rescued" test case that specifies -CApath]

edit1, fixed "rescued" test case that specifies -CApath;

edit2, fix the markdown that I broke in edit1

In the course of trying to help a friend with a problem with pip and ssl sites ([GitHub issue here][1]GitHub issue here), I've become confused about how the High Sierra /usr/bin/openssl finds its certificates. My "keg-only" openssl does not have any trouble with the site.

I've been scratching my head because an appropriate key resides in the Keychain utility (Determined by downloading the Mozilla cert bundle from the Curl site, finding the one cert that rescues the test case when provided via -CAfile, and comparing its fingerprint to certs in the Keychain app. See [the pip issue][1]the pip issue for gory details).

(alice)[14:26:32]~>>/usr/bin/openssl s_client -connect files.pythonhosted.org:443 -CApath /private/etc/ssl | head 2>&1 < /dev/null
depth=2 C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA
verify return:1
depth=1 C = BE, O = GlobalSign nv-sa, CN = GlobalSign CloudSSL CA - SHA256 - G3
verify return:1
depth=0 C = US, ST = California, L = San Francisco, O = "Fastly, Inc", CN = r.ssl.fastly.net
verify return:1
^C
(alice)[15:21:22]~>>```

What's going on?  Do the `CApath/CAfile` commands enable behavior that doesn't otherwise occur?

I'd love to understand what's going on.

Thanks!

[1]: https://github.com/pypa/pip/issues/766322]~>>

What's going on? Do the CApath/CAfile commands enable behavior that doesn't otherwise occur?

I'd love to understand what's going on.

Thanks!

[edit, fixed "rescued" test case that specifies -CApath]

In the course of trying to help a friend with a problem with pip and ssl sites ([GitHub issue here][1]), I've become confused about how the High Sierra /usr/bin/openssl finds its certificates. My "keg-only" openssl does not have any trouble with the site.

I've been scratching my head because an appropriate key resides in the Keychain utility (Determined by downloading the Mozilla cert bundle from the Curl site, finding the one cert that rescues the test case when provided via -CAfile, and comparing its fingerprint to certs in the Keychain app. See [the pip issue][1] for gory details).

(alice)[14:26:32]~>>/usr/bin/openssl s_client -connect files.pythonhosted.org:443 -CApath /private/etc/ssl | head 2>&1 < /dev/null
depth=2 C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA
verify return:1
depth=1 C = BE, O = GlobalSign nv-sa, CN = GlobalSign CloudSSL CA - SHA256 - G3
verify return:1
depth=0 C = US, ST = California, L = San Francisco, O = "Fastly, Inc", CN = r.ssl.fastly.net
verify return:1
^C
(alice)[15:21:22]~>>```

What's going on?  Do the `CApath/CAfile` commands enable behavior that doesn't otherwise occur?

I'd love to understand what's going on.

Thanks!

[1]: https://github.com/pypa/pip/issues/7663

edit1, fixed "rescued" test case that specifies -CApath;

edit2, fix the markdown that I broke in edit1

In the course of trying to help a friend with a problem with pip and ssl sites (GitHub issue here), I've become confused about how the High Sierra /usr/bin/openssl finds its certificates. My "keg-only" openssl does not have any trouble with the site.

I've been scratching my head because an appropriate key resides in the Keychain utility (Determined by downloading the Mozilla cert bundle from the Curl site, finding the one cert that rescues the test case when provided via -CAfile, and comparing its fingerprint to certs in the Keychain app. See the pip issue for gory details).

(alice)[14:26:32]~>>/usr/bin/openssl s_client -connect files.pythonhosted.org:443 -CApath /private/etc/ssl | head 2>&1 < /dev/null
depth=2 C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA
verify return:1
depth=1 C = BE, O = GlobalSign nv-sa, CN = GlobalSign CloudSSL CA - SHA256 - G3
verify return:1
depth=0 C = US, ST = California, L = San Francisco, O = "Fastly, Inc", CN = r.ssl.fastly.net
verify return:1
^C
(alice)[15:21:22]~>>

What's going on? Do the CApath/CAfile commands enable behavior that doesn't otherwise occur?

I'd love to understand what's going on.

Thanks!

deleted 117 characters in body

Source Link

edited Jan 28, 2020 at 23:23

hartzell

11
3

[edit, fixed "rescued" test case that specifies -CApath]

In the course of trying to help a friend with a problem with pip and ssl sites (GitHub issue here[GitHub issue here][1]), I've become confused about how the High Sierra /usr/bin/openssl finds its certificates. My "keg-only" openssl does not have any trouble with the site.

I've been scratching my head because an appropriate key resides in the Keychain utility (Determined by downloading the Mozilla cert bundle from the Curl site, finding the one cert that rescues the test case when provided via -CAfile, and comparing its fingerprint to certs in the Keychain app. See the pip issue[the pip issue][1] for gory details).

(alice)[14:2226:06]~>>32]~>>/usr/bin/openssl s_client -connect files.pythonhosted.org:443 -CApath /private/etc/ssl | head 2>&1 < /dev/null
depth=2 C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA
verify return:1
depth=1 C = BE, O = GlobalSign nv-sa, CN = GlobalSign CloudSSL CA - SHA256 - G3
verify error:num=20return:unable1
depth=0 toC get= localUS, issuerST certificate
verify= return:0
CONNECTED(00000005)
---
CertificateCalifornia, chain
L 0= s:/C=US/ST=California/L=SanSan Francisco/O=Fastly, Inc/CN=rO = "Fastly, Inc", CN = r.ssl.fastly.net
  verify ireturn:/C=BE/O=GlobalSign nv-sa/CN=GlobalSign CloudSSL CA1
^C
(alice)[15:21:22]~>>```

What's -going SHA256on? - G3
Do 1the s:/C=BE`CApath/O=GlobalSignCAfile` nv-sa/CN=GlobalSigncommands CloudSSLenable CAbehavior -that SHA256doesn't -otherwise G3occur?
 
I'd love i:/C=BE/O=GlobalSignto nv-sa/OU=Rootunderstand CA/CN=GlobalSignwhat's Rootgoing CAon.
---
Server certificateThanks!
-----BEGIN CERTIFICATE-----
^C[1]: https://github.com/pypa/pip/issues/7663

What's going on? Do the CApath/CAfile commands enable behavior that doesn't otherwise occur?

I'd love to understand what's going on.

Thanks!

In the course of trying to help a friend with a problem with pip and ssl sites (GitHub issue here), I've become confused about how the High Sierra /usr/bin/openssl finds its certificates. My "keg-only" openssl does not have any trouble with the site.

I've been scratching my head because an appropriate key resides in the Keychain utility (Determined by downloading the Mozilla cert bundle from the Curl site, finding the one cert that rescues the test case when provided via -CAfile, and comparing its fingerprint to certs in the Keychain app. See the pip issue for gory details).

(alice)[14:22:06]~>>/usr/bin/openssl s_client -connect files.pythonhosted.org:443 | head 2>&1
depth=1 C = BE, O = GlobalSign nv-sa, CN = GlobalSign CloudSSL CA - SHA256 - G3
verify error:num=20:unable to get local issuer certificate
verify return:0
CONNECTED(00000005)
---
Certificate chain
 0 s:/C=US/ST=California/L=San Francisco/O=Fastly, Inc/CN=r.ssl.fastly.net
   i:/C=BE/O=GlobalSign nv-sa/CN=GlobalSign CloudSSL CA - SHA256 - G3
 1 s:/C=BE/O=GlobalSign nv-sa/CN=GlobalSign CloudSSL CA - SHA256 - G3
   i:/C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
---
Server certificate
-----BEGIN CERTIFICATE-----
^C

What's going on? Do the CApath/CAfile commands enable behavior that doesn't otherwise occur?

I'd love to understand what's going on.

Thanks!

[edit, fixed "rescued" test case that specifies -CApath]

In the course of trying to help a friend with a problem with pip and ssl sites ([GitHub issue here][1]), I've become confused about how the High Sierra /usr/bin/openssl finds its certificates. My "keg-only" openssl does not have any trouble with the site.

I've been scratching my head because an appropriate key resides in the Keychain utility (Determined by downloading the Mozilla cert bundle from the Curl site, finding the one cert that rescues the test case when provided via -CAfile, and comparing its fingerprint to certs in the Keychain app. See [the pip issue][1] for gory details).

(alice)[14:26:32]~>>/usr/bin/openssl s_client -connect files.pythonhosted.org:443 -CApath /private/etc/ssl | head 2>&1 < /dev/null
depth=2 C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA
verify return:1
depth=1 C = BE, O = GlobalSign nv-sa, CN = GlobalSign CloudSSL CA - SHA256 - G3
verify return:1
depth=0 C = US, ST = California, L = San Francisco, O = "Fastly, Inc", CN = r.ssl.fastly.net
verify return:1
^C
(alice)[15:21:22]~>>```

What's going on?  Do the `CApath/CAfile` commands enable behavior that doesn't otherwise occur?

I'd love to understand what's going on.

Thanks!

[1]: https://github.com/pypa/pip/issues/7663

Source Link

asked Jan 28, 2020 at 22:24

hartzell

11
3

Loading

Stack Exchange Network

Return to Question