Re: [Bug-wget] Wget cannot validate https://ftp.gnu.org?

2017-10-19 Thread Jeffrey Walton 
On Wed, Oct 18, 2017 at 7:58 PM, Jeffrey Walton  wrote:
> On Mon, Oct 16, 2017 at 4:52 AM, Tim Rühsen  wrote:
>> ...
>>
>> Caveat: wget has been build with GnuTLS (3.5.15). The OpenSSL (1.1.0f)
>> code seems not to support --ca-directory !? It succeeds with both the
>> above tests. While we only actively support GnuTLS, we accept OpenSSL
>> code patches (if you like to provide one).
>
> I believe this is most of the patch you need. You or Simon will still
> need to touch it up. For example, I did not know how to handle a
> failure in OpenSSL from X509_VERIFY_PARAM_new().

Tim, hold-off on this at the moment. I want to talk to Matt Caswell
about it to ensure it meets requirements.

Mat is one of the OpenSSL devs. He is very helpful with his comments
and suggestions. In fact, he's the one who alerted me to
X509_V_FLAG_PARTIAL_CHAIN.

What I am wondering is... On a machine where both CAfile and CApath
are working as expected, are we only using CAfile; or are we using
CAPath and getting the CA Zoo if the directory is populated?

CAfile and CApath are names of s_client options that equate to the
parameters in calls like SSL_CTX_load_verify_locations. -CAfile is
actually equivalent to Wget's --ca-certificate. On some distros CApath
is broken so it appears OpenSSL does not trust anything by default.
But this is actually a bug in the utilities.

Jeff

Jeff

Re: [Bug-wget] Wget cannot validate https://ftp.gnu.org?

2017-10-18 Thread Jeffrey Walton 
On Mon, Oct 16, 2017 at 4:52 AM, Tim Rühsen  wrote:
> ...
>
> Caveat: wget has been build with GnuTLS (3.5.15). The OpenSSL (1.1.0f)
> code seems not to support --ca-directory !? It succeeds with both the
> above tests. While we only actively support GnuTLS, we accept OpenSSL
> code patches (if you like to provide one).

I believe this is most of the patch you need. You or Simon will still
need to touch it up. For example, I did not know how to handle a
failure in OpenSSL from X509_VERIFY_PARAM_new().

$ git diff > openssl.c.diff
$ cat openssl.c.diff
diff --git a/src/openssl.c b/src/openssl.c
index 0404d2d0..62d8b084 100644
--- a/src/openssl.c
+++ b/src/openssl.c
@@ -269,11 +269,36 @@ ssl_init (void)
* Since we want a good protection, we also use HIGH (that excludes
MD4 ciphers and some more)
*/
   if (opt.secure_protocol == secure_protocol_pfs)
-SSL_CTX_set_cipher_list (ssl_ctx,
"HIGH:MEDIUM:!RC4:!SRP:!PSK:!RSA:!aNULL@STRENGTH");
+SSL_CTX_set_cipher_list (ssl_ctx, "HIGH:!aNULL:!kRSA:!RC4:!MD5:!SRP:!PSK");

   SSL_CTX_set_default_verify_paths (ssl_ctx);
   SSL_CTX_load_verify_locations (ssl_ctx, opt.ca_cert, opt.ca_directory);

+  if (opt.ca_cert)
+{
+  /* Set X509_V_FLAG_PARTIAL_CHAIN to allow the client to anchor trust in
+   * a non-self-signed certificate. This defies RFC 4158 (Path Building)
+   * which defines a trust anchor in terms of a self-signed certificate.
+   * However, it substantially reduces attack surface by prunning the tree
+   * of unneeded trust points. For example, the cross-certified
+   * Let's Encrypt X3 CA, which protects gnu.org, appears as an
+   * intermediate CA to clients, can be used as a trust anchor without
+   * the entire IdentTrust PKI.
+   */
+  X509_VERIFY_PARAM *param = X509_VERIFY_PARAM_new();
+  if (!param)
+   {
+  /* TODO: How does Wget handle a malloc failure? */
+   }
+ else
+   {
+ /* Return value is the old options */
+ (void)X509_VERIFY_PARAM_set_flags(param,
X509_V_FLAG_PARTIAL_CHAIN);
+ SSL_CTX_set1_param(ssl_ctx, param);
+ X509_VERIFY_PARAM_free(param);
+   }
+}
+
   if (opt.crl_file)
 {
   X509_STORE *store = SSL_CTX_get_cert_store (ssl_ctx);


Jeff
diff --git a/src/openssl.c b/src/openssl.c
index 0404d2d0..62d8b084 100644
--- a/src/openssl.c
+++ b/src/openssl.c
@@ -269,11 +269,36 @@ ssl_init (void)
* Since we want a good protection, we also use HIGH (that excludes MD4 
ciphers and some more)
*/
   if (opt.secure_protocol == secure_protocol_pfs)
-SSL_CTX_set_cipher_list (ssl_ctx, 
"HIGH:MEDIUM:!RC4:!SRP:!PSK:!RSA:!aNULL@STRENGTH");
+SSL_CTX_set_cipher_list (ssl_ctx, "HIGH:!aNULL:!kRSA:!RC4:!MD5:!SRP:!PSK");
 
   SSL_CTX_set_default_verify_paths (ssl_ctx);
   SSL_CTX_load_verify_locations (ssl_ctx, opt.ca_cert, opt.ca_directory);
 
+  if (opt.ca_cert)
+{
+  /* Set X509_V_FLAG_PARTIAL_CHAIN to allow the client to anchor trust in
+   * a non-self-signed certificate. This defies RFC 4158 (Path Building)
+   * which defines a trust anchor in terms of a self-signed certificate.
+   * However, it substantially reduces attack surface by prunning the tree
+   * of unneeded trust points. For example, the cross-certified
+   * Let's Encrypt X3 CA, which protects gnu.org, appears as an
+   * intermediate CA to clients, can be used as a trust anchor without
+   * the entire IdentTrust PKI.
+   */ 
+  X509_VERIFY_PARAM *param = X509_VERIFY_PARAM_new();
+  if (!param)
+   {
+  /* TODO: How does Wget handle a malloc failure? */
+   }
+ else
+   {
+ /* Return value is the old options */
+ (void)X509_VERIFY_PARAM_set_flags(param, 
X509_V_FLAG_PARTIAL_CHAIN);
+ SSL_CTX_set1_param(ssl_ctx, param);
+ X509_VERIFY_PARAM_free(param);
+   }
+}
+
   if (opt.crl_file)
 {
   X509_STORE *store = SSL_CTX_get_cert_store (ssl_ctx);

Re: [Bug-wget] Wget cannot validate https://ftp.gnu.org?

2017-10-18 Thread Jeffrey Walton 
On Mon, Oct 16, 2017 at 4:52 AM, Tim Rühsen  wrote:
> Hi Jeffrey,
> ...
> Caveat: wget has been build with GnuTLS (3.5.15). The OpenSSL (1.1.0f)
> code seems not to support --ca-directory !? It succeeds with both the
> above tests. While we only actively support GnuTLS, we accept OpenSSL
> code patches (if you like to provide one).

Thanks Tim.

A little help would be appreciated. I found where --ca-certifcate is
called out in src/main.c, but I'm having trouble following the
connection between the option and a variable. I did not see an opt.c
or similar.

What is the variable of interest here? Or, maybe the source file of interest?

I believe the change is about as simple as
https://github.com/openssl/openssl/blob/master/apps/opt.c#L593 , but
I'd like to get it tested before I ask you or Simon to look at it.

Jeff

Re: [Bug-wget] Wget cannot validate https://ftp.gnu.org?

2017-10-16 Thread Tim Rühsen 
Hi Jeffrey,


I can't reproduce your issue on the first try (Debian unstable here).


That means the issuers cert (DST Root CA X3,O=Digital Signature Trust
Co.) is part of the systems's CA cert store.

$ ls -la /etc/ssl/certs/*X3*
lrwxrwxrwx 1 root root 53 27-10-11 09:39:52
/etc/ssl/certs/DST_Root_CA_X3.pem ->
/usr/share/ca-certificates/mozilla/DST_Root_CA_X3.crt

But now let's change the the CA directory to a place where no CAs are
stored *and* then add that X3 CA cert from
https://letsencrypt.org/certs/lets-encrypt-x3-cross-signed.pem.txt
(saved as x3.pem).

$ wget --ca-directory=/ --ca-certificate=x3.pem
https://ftp.gnu.org/gnu/libunistring/libunistring-0.9.7.tar.gz
(Download OK)

As a test that we really only load x3.pem:
$ wget --ca-directory=/ --ca-certificate=x3.pem https://google.com
ERROR: The certificate of ‘google.de’ is not trusted.
ERROR: The certificate of ‘google.de’ hasn't got a known issuer.
ERROR: The certificate of ‘google.de’ was signed using an insecure
algorithm.

Caveat: wget has been build with GnuTLS (3.5.15). The OpenSSL (1.1.0f)
code seems not to support --ca-directory !? It succeeds with both the
above tests. While we only actively support GnuTLS, we accept OpenSSL
code patches (if you like to provide one).

With Best Regards, Tim



On 10/15/2017 05:36 AM, Jeffrey Walton wrote:
> So it looks like the behavior below is inherited from OpenSSL:
> 
> $ openssl s_client -connect ftp.gnu.org:443 -servername ftp.gnu.org
> -CAfile ~/.cacert/lets-encrypt-root-x3.pem
> CONNECTED(0003)
> ...
> Verify return code: 2 (unable to get issuer certificate)
> 
> However, OpenSSL also has -partial-chain (thanks to Dave Thompson) so
> we can pin trust at the cross-certified Let's Encrypt X3 root:
> 
> $ openssl s_client -connect ftp.gnu.org:443 -servername ftp.gnu.org
> -CAfile ~/.cacert/lets-encrypt-root-x3.pem -partial_chain
> CONNECTED(0003)
> depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
> verify return:1
> depth=0 CN = ftp.gnu.org
> verify return:1
> ---
> Certificate chain
>  0 s:/CN=ftp.gnu.org
>i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
>  1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
>i:/O=Digital Signature Trust Co./CN=DST Root CA X3
> ---
>...
>Verify return code: 0 (ok)
> ---
> read:errno=0
> 
> Loog thorugh the Wget 1.18 manual
> (https://www.gnu.org/software/wget/manual/wget.html) I don't see a
> similar option.
> 
> So my question is, does Wget allow us to do the same? If so, then how
> do we do it?
> 
> Jeff
> 
> On Sat, Oct 14, 2017 at 6:53 PM, Jeffrey Walton  wrote:
>> I'm having trouble downloading tarballs from ftp.gnu.org using wget.
>>
>> wget --ca-certificate="$HOME/.cacert/lets-encrypt-root-x3.pem"
>> "https://ftp.gnu.org/gnu/libunistring/libunistring-0.9.7.tar.gz; -O
>> libunistring-0.9.7.tar.gz
>> --2017-10-14 17:59:40--
>> https://ftp.gnu.org/gnu/libunistring/libunistring-0.9.7.tar.gz
>> Resolving ftp.gnu.org (ftp.gnu.org)... 208.118.235.20, 2001:4830:134:3::b
>> Connecting to ftp.gnu.org (ftp.gnu.org)|208.118.235.20|:443... connected.
>> ERROR: cannot verify ftp.gnu.org's certificate, issued by 'CN=Let\'s
>> Encrypt Authority X3,O=Let\'s Encrypt,C=US':
>>   unable to get issuer certificate
>> To connect to ftp.gnu.org insecurely, use `--no-check-certificate'.
>>
>> The CA file lets-encrypt-root-x3.pem is provided at
>> https://letsencrypt.org/certs/lets-encrypt-x3-cross-signed.pem.txt,
>> and it is shown below. It has the CA bit set, basic constraints are
>> present, and proper key usage are present. It appears to be a valid ca
>> cert.
>>
>> The thing that looks unusual to me is, the addition of characters in
>> the distinguished name. For example, it appears Wget add a slash to
>> escape the single apostrophe in the common name.
>>
>> Does anyone have an idea what I might be doing wrong? Or if things are
>> working as expected, then how do I use the certificate to download the
>> file using Wget?
>>
>> **
>>
>> $ wget -V
>> GNU Wget 1.19.1 built on solaris2.11.
>>
>> -cares +digest -gpgme +https +ipv6 +iri +large-file -metalink +nls
>> +ntlm +opie -psl +ssl/openssl
>>
>> Wgetrc:
>> /usr/local/etc/wgetrc (system)
>> Locale:
>> /usr/local/share/locale
>> Compile:
>> gcc -DHAVE_CONFIG_H -DSYSTEM_WGETRC="/usr/local/etc/wgetrc"
>> -DLOCALEDIR="/usr/local/share/locale" -I. -I../lib -I../lib
>> -I/usr/local/include -DNDEBUG -D_REENTRANT -I/usr/include/pcre
>> -DNDEBUG -m64
>> Link:
>> gcc -I/usr/include/pcre -DNDEBUG -m64 -m64
>> -Wl,-rpath,/usr/local/lib64 -L/usr/local/lib64 -lpcre -luuid -lidn2
>> /usr/local/lib64/libssl.so /usr/local/lib64/libcrypto.so
>> -R/usr/local/lib64 -ldl -lz -lssl -lcrypto -ldl -lpthread
>> ftp-opie.o openssl.o http-ntlm.o ../lib/libgnu.a -lsocket -lnsl
>> -lnsl -lnsl -lsocket -lsocket /usr/local/lib64/libiconv.so
>> -R/usr/local/lib64 /usr/local/lib64/libunistring.so
>> /usr/local/lib64/libiconv.so

Re: [Bug-wget] Wget cannot validate https://ftp.gnu.org?

2017-10-14 Thread Jeffrey Walton 
So it looks like the behavior below is inherited from OpenSSL:

$ openssl s_client -connect ftp.gnu.org:443 -servername ftp.gnu.org
-CAfile ~/.cacert/lets-encrypt-root-x3.pem
CONNECTED(0003)
...
Verify return code: 2 (unable to get issuer certificate)

However, OpenSSL also has -partial-chain (thanks to Dave Thompson) so
we can pin trust at the cross-certified Let's Encrypt X3 root:

$ openssl s_client -connect ftp.gnu.org:443 -servername ftp.gnu.org
-CAfile ~/.cacert/lets-encrypt-root-x3.pem -partial_chain
CONNECTED(0003)
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify return:1
depth=0 CN = ftp.gnu.org
verify return:1
---
Certificate chain
 0 s:/CN=ftp.gnu.org
   i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
 1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
   i:/O=Digital Signature Trust Co./CN=DST Root CA X3
---
   ...
   Verify return code: 0 (ok)
---
read:errno=0

Loog thorugh the Wget 1.18 manual
(https://www.gnu.org/software/wget/manual/wget.html) I don't see a
similar option.

So my question is, does Wget allow us to do the same? If so, then how
do we do it?

Jeff

On Sat, Oct 14, 2017 at 6:53 PM, Jeffrey Walton  wrote:
> I'm having trouble downloading tarballs from ftp.gnu.org using wget.
>
> wget --ca-certificate="$HOME/.cacert/lets-encrypt-root-x3.pem"
> "https://ftp.gnu.org/gnu/libunistring/libunistring-0.9.7.tar.gz; -O
> libunistring-0.9.7.tar.gz
> --2017-10-14 17:59:40--
> https://ftp.gnu.org/gnu/libunistring/libunistring-0.9.7.tar.gz
> Resolving ftp.gnu.org (ftp.gnu.org)... 208.118.235.20, 2001:4830:134:3::b
> Connecting to ftp.gnu.org (ftp.gnu.org)|208.118.235.20|:443... connected.
> ERROR: cannot verify ftp.gnu.org's certificate, issued by 'CN=Let\'s
> Encrypt Authority X3,O=Let\'s Encrypt,C=US':
>   unable to get issuer certificate
> To connect to ftp.gnu.org insecurely, use `--no-check-certificate'.
>
> The CA file lets-encrypt-root-x3.pem is provided at
> https://letsencrypt.org/certs/lets-encrypt-x3-cross-signed.pem.txt,
> and it is shown below. It has the CA bit set, basic constraints are
> present, and proper key usage are present. It appears to be a valid ca
> cert.
>
> The thing that looks unusual to me is, the addition of characters in
> the distinguished name. For example, it appears Wget add a slash to
> escape the single apostrophe in the common name.
>
> Does anyone have an idea what I might be doing wrong? Or if things are
> working as expected, then how do I use the certificate to download the
> file using Wget?
>
> **
>
> $ wget -V
> GNU Wget 1.19.1 built on solaris2.11.
>
> -cares +digest -gpgme +https +ipv6 +iri +large-file -metalink +nls
> +ntlm +opie -psl +ssl/openssl
>
> Wgetrc:
> /usr/local/etc/wgetrc (system)
> Locale:
> /usr/local/share/locale
> Compile:
> gcc -DHAVE_CONFIG_H -DSYSTEM_WGETRC="/usr/local/etc/wgetrc"
> -DLOCALEDIR="/usr/local/share/locale" -I. -I../lib -I../lib
> -I/usr/local/include -DNDEBUG -D_REENTRANT -I/usr/include/pcre
> -DNDEBUG -m64
> Link:
> gcc -I/usr/include/pcre -DNDEBUG -m64 -m64
> -Wl,-rpath,/usr/local/lib64 -L/usr/local/lib64 -lpcre -luuid -lidn2
> /usr/local/lib64/libssl.so /usr/local/lib64/libcrypto.so
> -R/usr/local/lib64 -ldl -lz -lssl -lcrypto -ldl -lpthread
> ftp-opie.o openssl.o http-ntlm.o ../lib/libgnu.a -lsocket -lnsl
> -lnsl -lnsl -lsocket -lsocket /usr/local/lib64/libiconv.so
> -R/usr/local/lib64 /usr/local/lib64/libunistring.so
> /usr/local/lib64/libiconv.so -ldl -lpthread -R/usr/local/lib64
> -lsocket
>
> **
>
> $ openssl x509 -in $HOME/cacert/lets-encrypt-root-x3.pem -text -noout
> Certificate:
> Data:
> Version: 3 (0x2)
> Serial Number:
> 0a:01:41:42:00:00:01:53:85:73:6a:0b:85:ec:a7:08
> Signature Algorithm: sha256WithRSAEncryption
> Issuer: O=Digital Signature Trust Co., CN=DST Root CA X3
> Validity
> Not Before: Mar 17 16:40:46 2016 GMT
> Not After : Mar 17 16:40:46 2021 GMT
> Subject: C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3
> Subject Public Key Info:
> Public Key Algorithm: rsaEncryption
> Public-Key: (2048 bit)
> Modulus:
> 00:9c:d3:0c:f0:5a:e5:2e:47:b7:72:5d:37:83:b3:
> 68:63:30:ea:d7:35:26:19:25:e1:bd:be:35:f1:70:
> 92:2f:b7:b8:4b:41:05:ab:a9:9e:35:08:58:ec:b1:
> 2a:c4:68:87:0b:a3:e3:75:e4:e6:f3:a7:62:71:ba:
> 79:81:60:1f:d7:91:9a:9f:f3:d0:78:67:71:c8:69:
> 0e:95:91:cf:fe:e6:99:e9:60:3c:48:cc:7e:ca:4d:
> 77:12:24:9d:47:1b:5a:eb:b9:ec:1e:37:00:1c:9c:
> ac:7b:a7:05:ea:ce:4a:eb:bd:41:e5:36:98:b9:cb:
> fd:6d:3c:96:68:df:23:2a:42:90:0c:86:74:67:c8:
> 7f:a5:9a:b8:52:61:14:13:3f:65:e9:82:87:cb:db:
>

[Bug-wget] Wget cannot validate https://ftp.gnu.org?

2017-10-14 Thread Jeffrey Walton 
I'm having trouble downloading tarballs from ftp.gnu.org using wget.

wget --ca-certificate="$HOME/.cacert/lets-encrypt-root-x3.pem"
"https://ftp.gnu.org/gnu/libunistring/libunistring-0.9.7.tar.gz; -O
libunistring-0.9.7.tar.gz
--2017-10-14 17:59:40--
https://ftp.gnu.org/gnu/libunistring/libunistring-0.9.7.tar.gz
Resolving ftp.gnu.org (ftp.gnu.org)... 208.118.235.20, 2001:4830:134:3::b
Connecting to ftp.gnu.org (ftp.gnu.org)|208.118.235.20|:443... connected.
ERROR: cannot verify ftp.gnu.org's certificate, issued by 'CN=Let\'s
Encrypt Authority X3,O=Let\'s Encrypt,C=US':
  unable to get issuer certificate
To connect to ftp.gnu.org insecurely, use `--no-check-certificate'.

The CA file lets-encrypt-root-x3.pem is provided at
https://letsencrypt.org/certs/lets-encrypt-x3-cross-signed.pem.txt,
and it is shown below. It has the CA bit set, basic constraints are
present, and proper key usage are present. It appears to be a valid ca
cert.

The thing that looks unusual to me is, the addition of characters in
the distinguished name. For example, it appears Wget add a slash to
escape the single apostrophe in the common name.

Does anyone have an idea what I might be doing wrong? Or if things are
working as expected, then how do I use the certificate to download the
file using Wget?

**

$ wget -V
GNU Wget 1.19.1 built on solaris2.11.

-cares +digest -gpgme +https +ipv6 +iri +large-file -metalink +nls
+ntlm +opie -psl +ssl/openssl

Wgetrc:
/usr/local/etc/wgetrc (system)
Locale:
/usr/local/share/locale
Compile:
gcc -DHAVE_CONFIG_H -DSYSTEM_WGETRC="/usr/local/etc/wgetrc"
-DLOCALEDIR="/usr/local/share/locale" -I. -I../lib -I../lib
-I/usr/local/include -DNDEBUG -D_REENTRANT -I/usr/include/pcre
-DNDEBUG -m64
Link:
gcc -I/usr/include/pcre -DNDEBUG -m64 -m64
-Wl,-rpath,/usr/local/lib64 -L/usr/local/lib64 -lpcre -luuid -lidn2
/usr/local/lib64/libssl.so /usr/local/lib64/libcrypto.so
-R/usr/local/lib64 -ldl -lz -lssl -lcrypto -ldl -lpthread
ftp-opie.o openssl.o http-ntlm.o ../lib/libgnu.a -lsocket -lnsl
-lnsl -lnsl -lsocket -lsocket /usr/local/lib64/libiconv.so
-R/usr/local/lib64 /usr/local/lib64/libunistring.so
/usr/local/lib64/libiconv.so -ldl -lpthread -R/usr/local/lib64
-lsocket

**

$ openssl x509 -in $HOME/cacert/lets-encrypt-root-x3.pem -text -noout
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
0a:01:41:42:00:00:01:53:85:73:6a:0b:85:ec:a7:08
Signature Algorithm: sha256WithRSAEncryption
Issuer: O=Digital Signature Trust Co., CN=DST Root CA X3
Validity
Not Before: Mar 17 16:40:46 2016 GMT
Not After : Mar 17 16:40:46 2021 GMT
Subject: C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:9c:d3:0c:f0:5a:e5:2e:47:b7:72:5d:37:83:b3:
68:63:30:ea:d7:35:26:19:25:e1:bd:be:35:f1:70:
92:2f:b7:b8:4b:41:05:ab:a9:9e:35:08:58:ec:b1:
2a:c4:68:87:0b:a3:e3:75:e4:e6:f3:a7:62:71:ba:
79:81:60:1f:d7:91:9a:9f:f3:d0:78:67:71:c8:69:
0e:95:91:cf:fe:e6:99:e9:60:3c:48:cc:7e:ca:4d:
77:12:24:9d:47:1b:5a:eb:b9:ec:1e:37:00:1c:9c:
ac:7b:a7:05:ea:ce:4a:eb:bd:41:e5:36:98:b9:cb:
fd:6d:3c:96:68:df:23:2a:42:90:0c:86:74:67:c8:
7f:a5:9a:b8:52:61:14:13:3f:65:e9:82:87:cb:db:
fa:0e:56:f6:86:89:f3:85:3f:97:86:af:b0:dc:1a:
ef:6b:0d:95:16:7d:c4:2b:a0:65:b2:99:04:36:75:
80:6b:ac:4a:f3:1b:90:49:78:2f:a2:96:4f:2a:20:
25:29:04:c6:74:c0:d0:31:cd:8f:31:38:95:16:ba:
a8:33:b8:43:f1:b1:1f:c3:30:7f:a2:79:31:13:3d:
2d:36:f8:e3:fc:f2:33:6a:b9:39:31:c5:af:c4:8d:
0d:1d:64:16:33:aa:fa:84:29:b6:d4:0b:c0:d8:7d:
c3:93
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints: critical
CA:TRUE, pathlen:0
X509v3 Key Usage: critical
Digital Signature, Certificate Sign, CRL Sign
Authority Information Access:
OCSP - URI:http://isrg.trustid.ocsp.identrust.com
CA Issuers - URI:http://apps.identrust.com/roots/dstrootcax3.p7c

X509v3 Authority Key Identifier:

keyid:C4:A7:B1:A4:7B:2C:71:FA:DB:E1:4B:90:75:FF:C4:15:60:85:89:10

X509v3 Certificate Policies:
Policy: 2.23.140.1.2.1
Policy: 1.3.6.1.4.1.44947.1.1.1
  CPS: http://cps.root-x1.letsencrypt.org

X509v3 CRL Distribution Points:

Full Name:
  URI:http://crl.identrust.com/DSTROOTCAX3CRL.crl

X509v3 Subject Key Identifier: