You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by William A Rowe Jr <wr...@rowe-clan.net> on 2018/10/13 18:35:49 UTC
Re: svn commit: r1843478 - /httpd/test/framework/trunk/t/ssl/ocsp.t
On Wed, Oct 10, 2018 at 12:27 PM <ji...@apache.org> wrote:
> Author: jim
> Date: Wed Oct 10 17:27:33 2018
> New Revision: 1843478
>
> URL: http://svn.apache.org/viewvc?rev=1843478&view=rev
> Log:
> Better method... just check return status
>
> Modified:
> httpd/test/framework/trunk/t/ssl/ocsp.t
>
> Modified: httpd/test/framework/trunk/t/ssl/ocsp.t
> URL:
> http://svn.apache.org/viewvc/httpd/test/framework/trunk/t/ssl/ocsp.t?rev=1843478&r1=1843477&r2=1843478&view=diff
>
> ==============================================================================
> --- httpd/test/framework/trunk/t/ssl/ocsp.t (original)
> +++ httpd/test/framework/trunk/t/ssl/ocsp.t Wed Oct 10 17:27:33 2018
> @@ -21,7 +21,7 @@ Apache::TestRequest::module('ssl_ocsp');
> # support in earlier versions without messing around with stderr
> my $openssl = Apache::TestSSLCA::openssl();
> if (!have_min_apache_version('2.4.26')
> - or `$openssl list-standard-commands 2>/dev/null` !~ /ocsp/) {
> + or system("$openssl ocsp 2>/dev/null") == 0) {
>
On Windows, /dev/null is invalid (output target nul, eg NUL).
On every platform this is an always-fail noop, since `openssl ocsp` always
results in an error. Not enough arguments. You disabled this test on all
environments, please revert.
One test without extraneous stdout garbage might be to test ( `$openssl
ocsp -help` !~ /Usage:/ ) ... in theory this would both succeed (success
0), eat stdout, and there should be no Usage: instructions if the ocsp verb
doesn't exist.
Thoughts?
Re: svn commit: r1843478 - /httpd/test/framework/trunk/t/ssl/ocsp.t
Posted by Jim Jagielski <ji...@jaguNET.com>.
Forget this. My patch works and is correct and handles the specific situation which is noted in the test case itself related to older versions. It is an IMPROVEMENT over what we currently have.
The sole reason why Bill doesn't like it is because *I* committed it.
Whatever. I have no desire or patience with him anymore. I could not care less what patch is included.
Re: svn commit: r1843478 - /httpd/test/framework/trunk/t/ssl/ocsp.t
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Mon, Oct 15, 2018 at 10:10 AM Jim Jagielski <ji...@jagunet.com> wrote:
> -1 (veto).
>
Correct. Your three commits against jorton's implementation are vetoed.
They were incorrect.
> 'list' is not a valid command.
>
You are wrong.
The list-standard-commands feature was dropped from OpenSSL 1.1.0 and
onwards.
https://www.openssl.org/docs/man1.1.0/apps/openssl.html
This doesn't cover OpenSSL 1.0.1 and 1.0.2, which exhibit the following
result;
$ LD_LIBRARY_PATH=./lib bin/openssl list -help 2>&1
openssl:Error: 'list' is an invalid command.
Standard commands
asn1parse ca ciphers cms
crl crl2pkcs7 dgst dh
dhparam dsa dsaparam ec
ecparam enc engine errstr
gendh gendsa genpkey genrsa
nseq ocsp passwd pkcs12
pkcs7 pkcs8 pkey pkeyparam
pkeyutl prime rand req
rsa rsautl s_client s_server
s_time sess_id smime speed
spkac srp ts verify
version x509
Message Digest commands (see the `dgst' command for more details)
md4 md5 mdc2 rmd160
sha sha1
Cipher commands (see the `enc' command for more details)
aes-128-cbc aes-128-ecb aes-192-cbc aes-192-ecb
aes-256-cbc aes-256-ecb base64 bf
bf-cbc bf-cfb bf-ecb bf-ofb
camellia-128-cbc camellia-128-ecb camellia-192-cbc camellia-192-ecb
camellia-256-cbc camellia-256-ecb cast cast-cbc
cast5-cbc cast5-cfb cast5-ecb cast5-ofb
des des-cbc des-cfb des-ecb
des-ede des-ede-cbc des-ede-cfb des-ede-ofb
des-ede3 des-ede3-cbc des-ede3-cfb des-ede3-ofb
des-ofb des3 desx idea
idea-cbc idea-cfb idea-ecb idea-ofb
rc2 rc2-40-cbc rc2-64-cbc rc2-cbc
rc2-cfb rc2-ecb rc2-ofb rc4
rc4-40 seed seed-cbc seed-cfb
seed-ecb seed-ofb
While the result code is 1 (failure), using the `cmd` expression this
succeeds in providing the verb list.
It's helpful if we solve for all cases, and not one developer's specific
case.
Re: svn commit: r1843478 - /httpd/test/framework/trunk/t/ssl/ocsp.t
Posted by Jim Jagielski <ji...@jaguNET.com>.
-1 (veto).
'list' is not a valid command.
> On Oct 15, 2018, at 11:04 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>
> On Mon, Oct 15, 2018 at 7:52 AM Jim Jagielski <jim@jagunet.com <ma...@jagunet.com>> wrote:
>
> And lest we forget, the orig version used:
>
> $openssl list -commands
>
> I have no idea what version of openssl supports 'list'. The result
> of which was that the ocsp testing was ALWAYS SKIPPED.
>
> No, it wasn't skipped. We weren't looking at the result code, but examining stdout, and jorton's original test was correct for everyone testing with OpenSSL 1.1.0 and later.
Show me.
Re: svn commit: r1843478 - /httpd/test/framework/trunk/t/ssl/ocsp.t
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Mon, Oct 15, 2018 at 7:52 AM Jim Jagielski <ji...@jagunet.com> wrote:
>
> And lest we forget, the orig version used:
>
> $openssl list -commands
>
> I have no idea what version of openssl supports 'list'. The result
> of which was that the ocsp testing was ALWAYS SKIPPED.
>
No, it wasn't skipped. We weren't looking at the result code, but examining
stdout, and jorton's original test was correct for everyone testing with
OpenSSL 1.1.0 and later.
It was also correct for 1.0.2 and prior if the perl implementation was
capturing stderr to stdout as a result of `openssl list`, because in these
versions, the entire command list is dumped to stderr for the unrecognized
verb 'list', until you redirected stderr to /dev/null. list -commands was
introduced in 1.1.0. Also 1.1.0 dropped the list-standard-commands.
A correct solution, now committed, uses the original implementation but now
lumps stderr into stdout. For all flavors of OpenSSL we have a verb list to
evaluate.
I still ask whether testing system("$openssl ocsp -help") for a positive
(0) result code makes sense, but that reintroduces a >/dev/null 2>&1 which
I'd pointed out earlier breaks win32 testing because NUL <> /dev/null on
that platform, so it seemed simpler just to revert to jorton's solve.
Re: svn commit: r1843478 - /httpd/test/framework/trunk/t/ssl/ocsp.t
Posted by Jim Jagielski <ji...@jaguNET.com>.
> On Oct 14, 2018, at 3:59 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>
> $ openssl xyz >/dev/null
> Invalid command 'xyz'; type "help" for a list.
> $ echo $?
> 1
> $ openssl version
> OpenSSL 1.1.0i-fips 14 Aug 2018
>
> I have no idea which bastardization of the openssl command line tool you are using which returns success for bad verbs.
>
It looks like your version suffers from such "bastardization" as well....
And lest we forget, the orig version used:
$openssl list -commands
I have no idea what version of openssl supports 'list'. The result
of which was that the ocsp testing was ALWAYS SKIPPED.
Re: svn commit: r1843478 - /httpd/test/framework/trunk/t/ssl/ocsp.t
Posted by Jim Jagielski <ji...@jaguNET.com>.
> On Oct 16, 2018, at 11:36 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>
> To button this issue up, it's clear to me that Jim had transposed the meaning of result values from posix commands, and that was the origin of irrationality in this discussion.
>
Actually, I did not. But thanks for playing. I will ignore the implied insult.
Re: svn commit: r1843478 - /httpd/test/framework/trunk/t/ssl/ocsp.t
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
To button this issue up, it's clear to me that Jim had transposed the
meaning of result values from posix commands, and that was the origin of
irrationality in this discussion.
Beyond the misunderstanding, the actual behavior of openssl in 1.0.x and
prior was inane, and led to Jim's confusion, and my earlier hint to add
-help would not have improved the situation.
On Sun, Oct 14, 2018 at 3:50 PM Rainer Jung <ra...@kippdata.de> wrote:
> Am 14.10.2018 um 21:59 schrieb William A Rowe Jr:
> > On Sun, Oct 14, 2018 at 8:32 AM Jim Jagielski <jim@jagunet.com
> > <ma...@jagunet.com>> wrote:
> >
> > All we are checking is the error code. Nothing else.
> >
> > % openssl version
> > OpenSSL 1.0.2p 14 Aug 2018
>
The result of this command, $? had returns a value 0, success.
> > % openssl ocsp 2>/dev/null
> > % print $?
> > 1
>
This result code is failure. A non-zero posix result code is failure.
See `man 3 system`. (See also perldoc system, search for LIST to learn
that the result code is shifted 8 bits, returning 256 for '1'.)
> % openssl foo 2>/dev/null
> > % print $?
> > 0
>
This result code is success, return code 0, no error. An unrecognized verb
was not an error!?!
> > With 1.1.1, both return 1, but so what, we know that it has oscp.
>
With 1.1.0 and 1.1.1 the failure result code 1 is correct, as shown below.
> I can confirm this behavior for normal OpenSSL 1.0.2p.
>
I also confirm, and my apologies for presuming this was some fork's
behavior. OpenSSL 1.0.x behavior was truly incomprehensible as shown
below...
And worse, my suggested fix to jim was also erroneous, in 1.0.2 and prior
the ocsp -help flag is similarly treated as an error. Using 1.0.2 branch
(frozen/final) from git;
$ openssl version
OpenSSL 1.0.2l-dev xx XXX xxxx
$ echo $?
0
$ openssl foo
openssl:Error: 'foo' is an invalid command.
Standard commands
asn1parse ca ciphers cms
[...]
$ echo $?
0
$ openssl ocsp
OCSP utility
Usage ocsp [options]
where options are
-out file output filename
[...]
$ echo $?
1
$ openssl ocsp -help
OCSP utility
Usage ocsp [options]
where options are
-out file output filename
[...]
$ echo $?
1
Success, success, failure, failure. Which makes no fricking sense, and this
was the case jim sought to solve for.
Once we are at 1.1.0, this all starts to right itself;
$ openssl version
OpenSSL 1.1.0i-fips 14 Aug 2018
$ echo $?
0
$ openssl foo
Invalid command 'foo'; type "help" for a list.
$ echo $?
1
$ openssl ocsp 2>&1
ocsp: Use -help for summary.
$ echo $?
1
$ openssl ocsp -help 2>&1
Usage: ocsp [options]
Valid options are:
-help Display this summary
-out outfile Output filename
[...]
$ echo $?
0
Success, failure, failure, success, as would be expected.
It's plainly obvious that the result code from openssl main() cannot be
trusted for evaluating features between 1.0.x and 1.1.x, and is the reason
Jim's patch was defective.
So we are back to testing the output of `openssl list -commands 2>&1`,
evaluating stdout on 1.1.x, and stderr on 1.0.x. Unless Jim's veto stands?
> On Mon, Oct 15, 2018 at 10:07 AM Jim Jagielski <ji...@jagunet.com> wrote:
>>
>> -1 (veto)
>>
>> Please revert. 'list' is NOT a command and this causes OCSP to be
skipped.
On Mon, Oct 15, 2018 at 10:20 AM Jim Jagielski <ji...@jagunet.com> wrote:
>
> Forget this. My patch works and is correct and handles the specific
situation which is noted in the test case itself related to older versions.
It is an IMPROVEMENT over what we currently have.
Your patch treated success as failure and failure as success.
Your patch had enabled ocsp always in 1.1.x because `openssl ocsp` always
returns failure. It was disabling the test when absent from 1.0.x because
`openssl ocsp` returned failure, while it enabled the test with 1.0.x
because `openssl {unknown}` returned success when unrecognized.
Your patch introduced a regression because ocsp in 1.1.x must not be tested
when configured no-ocsp; this was harmful.
My suggestion of `openssl ocsp -help` would not have fixed this, because
then the test would have been disabled in 1.1.x when ocsp was available,
and enabled when ocsp was absent. However, using a valid command would have
helped identify the underlying logic error.
Joe's original code enabled ocsp correctly in 1.1.x because `openssl list
-commands` works, and the /ocsp/ string is found. Joe's original code never
enabled the test in 1.0.2, which was mostly harmless, but less effective.
My patch to Joe's original code works because `openssl list -commands`
fails so the command list is emitted to stderr, where we now detect /ocsp/.
> The sole reason why Bill doesn't like it is because *I* committed it.
By now, we should agree that this tantrum was uncalled for, in light of
these multiple defective patches. The fact that you couldn't believe your
logic might be erroneous wasn't an excuse to have a meltdown or take a code
discussion personally.
> Whatever. I have no desire or patience with him anymore. I could not care
less what patch is included.
You sent this 13 minutes after your veto, so I will read this as
withdrawing your veto above. If I'm misunderstanding, please state your
veto again to avoid confusion and I will revert to jorton's logic, removing
my fix for 1.0.x.
Please stop assuming ill will when your defects are pointed out. Your
misunderstanding of system() is not my problem. My issues were with the
'try it until something looks like it works' approach of your patches, and
not you as a person.
Re: svn commit: r1843478 - /httpd/test/framework/trunk/t/ssl/ocsp.t
Posted by Dennis Clarke <dc...@blastwave.org>.
On 10/15/2018 01:25 PM, William A Rowe Jr wrote:
> On Sun, Oct 14, 2018 at 4:38 PM Dennis Clarke <dclarke@blastwave.org
> <ma...@blastwave.org>> wrote:
>
>
> As a red herring that illustrates how oddball the situation could get :
>
> $ /usr/sfw/bin/openssl version 2>&1 | cut -f1 -d\(
> OpenSSL 0.9.7d 17 Mar 2004
> [...]
> Segmentation Fault(coredump)
>
>
> I think we can safely ignore OpenSSL 0.9.7 as the final release was over
> 11 years ago.
Like I was saying it is a red^H^H^Hdead herring :-\
> The 0.9.8 will only be encountered on rusting RHEL 5 (mainstream EOL a
> year ago in spring) and similarly ancient installations across other
> os/architectures.
*nod*
> 1.0.0 only saw the light of day in broad adoption via
> SLES 11 (mainstream EOL spring next year).
The Oracle folks pushed out 1.0.2 onto legacy Solaris a while ago :
$ which openssl
/usr/bin/openssl
$ /usr/bin/openssl version
OpenSSL 1.0.2n 7 Dec 2017
> There are a good number of 1.0.1 installations lingering around...
tons.
> Breaking 1.0.1 support would seem unwise
A disaster is what I am thinking.
> but we probably should start
> ignoring 0.9.8 and 1.0.0 for all practical purposes.
Anything pre 1.x.y should be considered rust.
Dennis
Re: svn commit: r1843478 - /httpd/test/framework/trunk/t/ssl/ocsp.t
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Sun, Oct 14, 2018 at 4:38 PM Dennis Clarke <dc...@blastwave.org> wrote:
>
> As a red herring that illustrates how oddball the situation could get :
>
> $ /usr/sfw/bin/openssl version 2>&1 | cut -f1 -d\(
> OpenSSL 0.9.7d 17 Mar 2004
> [...]
> Segmentation Fault(coredump)
>
I think we can safely ignore OpenSSL 0.9.7 as the final release was over 11
years ago.
Right now, only 1.1.1, 1.1.0 (12 month EOL clock started), and 1.0.2
(through 2019) are recognized by the OpenSSL project.
The 0.9.8 will only be encountered on rusting RHEL 5 (mainstream EOL a year
ago in spring) and similarly ancient installations across other
os/architectures. 1.0.0 only saw the light of day in broad adoption via
SLES 11 (mainstream EOL spring next year). There are a good number of 1.0.1
installations lingering around... everything shipped between and including
RHEL 6 and RHEL 7 including SLES 12 and Ubuntu 12.04 and 14.04 shipped with
that flavor.
Breaking 1.0.1 support would seem unwise, but we probably should start
ignoring 0.9.8 and 1.0.0 for all practical purposes.
Re: svn commit: r1843478 - /httpd/test/framework/trunk/t/ssl/ocsp.t
Posted by Dennis Clarke <dc...@blastwave.org>.
On 10/14/2018 05:45 PM, William A Rowe Jr wrote:
> Dennis, just to confirm ... is this build ocsp enabled..
Enabled and broken. At least on Solaris 10 sparc with recent patches.
OpenSSL 1.1.1 works just fine. See below.
OpenSSL 1.0.2n also blows up :
$ /usr/bin/openssl version
OpenSSL 1.0.2n 7 Dec 2017
$ /usr/bin/openssl ocsp -issuer /tmp/foo_chain -cert /tmp/foo_cert -text
-url http://ocsp.int-x3.letsencrypt.org
OCSP Request Data:
Version: 1 (0x0)
Requestor List:
Certificate ID:
Hash Algorithm: sha1
Issuer Name Hash: 7EE66AE7729AB3FCF8A220646C16A12D6071085D
Issuer Key Hash: A84A6A63047DDDBAE6D139B7A64565EFF3A8ECA1
Serial Number: 039048428EE710E751C1EC96E355B05FADF7
Request Extensions:
OCSP Nonce:
041027F5719EF8A6D928B5A5AC8CC46BA10C
Error querying OCSP responder
4275879124:error:27076072:OCSP routines:PARSE_HTTP_LINE1:server response
error:ocsp_ht.c:314:Code=400,Reason=Bad Request
$
Not really a blow up .. just an "oops .. don't touch me" result.
OpenSSL 1.1.1 is happy all day long :
$ openssl ocsp -issuer /tmp/foo_chain -cert /tmp/foo_cert -text -url
http://ocsp.int-x3.letsencrypt.org
OCSP Request Data:
Version: 1 (0x0)
Requestor List:
Certificate ID:
Hash Algorithm: sha1
Issuer Name Hash: 7EE66AE7729AB3FCF8A220646C16A12D6071085D
Issuer Key Hash: A84A6A63047DDDBAE6D139B7A64565EFF3A8ECA1
Serial Number: 039048428EE710E751C1EC96E355B05FADF7
Request Extensions:
OCSP Nonce:
0410AF283079082966EF04E8805C8D9215EB
OCSP Response Data:
OCSP Response Status: successful (0x0)
Response Type: Basic OCSP Response
Version: 1 (0x0)
Responder Id: C = US, O = Let's Encrypt, CN = Let's Encrypt
Authority X3
Produced At: Oct 12 02:56:00 2018 GMT
Responses:
Certificate ID:
Hash Algorithm: sha1
Issuer Name Hash: 7EE66AE7729AB3FCF8A220646C16A12D6071085D
Issuer Key Hash: A84A6A63047DDDBAE6D139B7A64565EFF3A8ECA1
Serial Number: 039048428EE710E751C1EC96E355B05FADF7
Cert Status: good
This Update: Oct 12 02:00:00 2018 GMT
Next Update: Oct 19 02:00:00 2018 GMT
Signature Algorithm: sha256WithRSAEncryption
76:f4:7f:ff:4a:c5:26:c2:60:88:fe:ef:90:dd:c7:0a:39:fd:
d0:df:fe:17:4b:71:78:08:60:e0:ee:14:4b:98:91:ef:77:59:
81:51:ee:cc:b6:16:99:92:7d:98:64:e2:a7:be:f2:cb:24:61:
47:67:0c:62:2c:06:95:4b:73:34:0c:7a:ce:ce:1c:27:85:14:
97:f7:2e:76:3e:21:8b:83:ab:29:1f:55:48:25:f4:61:6a:d8:
bf:65:10:90:71:04:10:45:4d:9a:37:84:02:9e:eb:06:45:3f:
85:4c:e4:a4:b6:3f:54:fa:4d:4b:9e:d4:8f:1b:44:4f:fb:6c:
e3:18:11:ba:3c:e1:21:64:97:4b:4a:28:d7:c5:b1:b3:46:fe:
36:99:da:da:aa:e4:32:57:a1:14:d5:54:b9:6d:e4:49:59:a2:
77:d4:87:97:95:8d:e6:7c:5b:64:db:60:ab:3e:e3:a7:a6:bc:
00:0e:b8:dd:0c:42:a0:18:f8:d5:73:16:80:50:3c:b3:24:d0:
01:da:3d:09:29:4e:93:d7:81:27:91:39:9c:67:99:53:d4:5f:
ab:6a:42:67:1e:ca:9d:4c:40:a7:f8:71:e4:bf:43:e8:a0:20:
62:9c:d5:25:16:8a:41:f5:70:85:c4:e4:45:9d:b6:95:4f:4f:
79:3f:84:53
WARNING: no nonce in response
Response verify OK
/tmp/foo_cert: good
This Update: Oct 12 02:00:00 2018 GMT
Next Update: Oct 19 02:00:00 2018 GMT
$
$
Ye old old OpenSSL 0.9.7d 17 Mar 2004 tries and then dumps core :
$
$ /usr/sfw/bin/openssl ocsp -issuer /tmp/foo_chain -cert /tmp/foo_cert
-text -url http://ocsp.int-x3.letsencrypt.org
OCSP Request Data:
Version: 1 (0x0)
Requestor List:
Certificate ID:
Hash Algorithm: sha1
Issuer Name Hash: 7EE66AE7729AB3FCF8A220646C16A12D6071085D
Issuer Key Hash: A84A6A63047DDDBAE6D139B7A64565EFF3A8ECA1
Serial Number: 039048428EE710E751C1EC96E355B05FADF7
Request Extensions:
OCSP Nonce:
04109FDC7D814DC7A57BFDB2ACB6C906247B
Error querying OCSP responsder
1035:error:27070072:OCSP routines:OCSP_sendreq_bio:server response
error:/on10/build-nd/ON10_P042/usr/src/common/openssl/crypto/ocsp/ocsp_ht.c:147:Code=400,Reason=Bad
Request
Segmentation Fault(coredump)
$
So the feature is there ... just broken.
How I tested this was :
$ openssl version
OpenSSL 1.1.1 11 Sep 2018
$ openssl s_client -connect node000.genunix.com:443 < /dev/null 2>&1
CONNECTED(00000005)
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify return:1
depth=0 CN = *.genunix.com
verify return:1
---
Certificate chain
0 s:CN = *.genunix.com
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
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIGBDCCBOygAwIBAgISA5BIQo7nEOdRweyW41WwX633MA0GCSqGSIb3DQEBCwUA
MEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQD
ExpMZXQncyBFbmNyeXB0IEF1dGhvcml0eSBYMzAeFw0xODA4MDQwMTU2MDZaFw0x
ODExMDIwMTU2MDZaMBgxFjAUBgNVBAMMDSouZ2VudW5peC5jb20wggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDOi3zn/l9/7shHNxXF2aUlv1Cy+lze/QFE
enan5hjsv52lCmiibZlwf0/3M8uQCazhaznHVMYiaBX5h3vAhR6/t47ckMlBows8
X4AP9PvvAR+zdS2EFWQ+bwAGMwuD/q7ZDoT0tyV6KIS7W9xZjd9SVleTyIAFH/rN
WRJxq80jJRpVX3gBdN8crM/rxgp98PJYorfCrF7EeDdGqRrzO/Q3BueCuU51a8kJ
Idbh7uIwUcyzPNdNMI7IJy2TxnKbb+ocg03ounWa42VBnfkeK1GM+t1r62zWyHs1
R9CetTpnmKNUWInZaHb142tjz/ZHxWpvz6wWLiDAUg9hokDI1Ld5AgMBAAGjggMU
MIIDEDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUF
BwMCMAwGA1UdEwEB/wQCMAAwHQYDVR0OBBYEFCCTnlBN2NePVn8eZBqdjyfC7rEM
MB8GA1UdIwQYMBaAFKhKamMEfd265tE5t6ZFZe/zqOyhMG8GCCsGAQUFBwEBBGMw
YTAuBggrBgEFBQcwAYYiaHR0cDovL29jc3AuaW50LXgzLmxldHNlbmNyeXB0Lm9y
ZzAvBggrBgEFBQcwAoYjaHR0cDovL2NlcnQuaW50LXgzLmxldHNlbmNyeXB0Lm9y
Zy8wGAYDVR0RBBEwD4INKi5nZW51bml4LmNvbTCB/gYDVR0gBIH2MIHzMAgGBmeB
DAECATCB5gYLKwYBBAGC3xMBAQEwgdYwJgYIKwYBBQUHAgEWGmh0dHA6Ly9jcHMu
bGV0c2VuY3J5cHQub3JnMIGrBggrBgEFBQcCAjCBngyBm1RoaXMgQ2VydGlmaWNh
dGUgbWF5IG9ubHkgYmUgcmVsaWVkIHVwb24gYnkgUmVseWluZyBQYXJ0aWVzIGFu
ZCBvbmx5IGluIGFjY29yZGFuY2Ugd2l0aCB0aGUgQ2VydGlmaWNhdGUgUG9saWN5
IGZvdW5kIGF0IGh0dHBzOi8vbGV0c2VuY3J5cHQub3JnL3JlcG9zaXRvcnkvMIIB
AwYKKwYBBAHWeQIEAgSB9ASB8QDvAHUA23Sv7ssp7LH+yj5xbSzluaq7NveEcYPH
XZ1PN7Yfv2QAAAFlAt0Q+gAABAMARjBEAiA+t4J1uZItOOTamCF9XsE+9S2hPpNN
bCsqHcn42p8b5AIgVi5jlTH5bSjiBkweb/nRExf6PpFZhvrb20hojYweFWwAdgAp
PFGWVMg5ZbqqUPxYB9S3b79Yeily3KTDDPTlRUf0eAAAAWUC3REOAAAEAwBHMEUC
IHd8ktNpgmeQkZQ9y+3I0o8IKJKyu9VkZ065or7lZSkIAiEA5t7ThHkcqY9QPPul
wsvQrCeMlgYfjNTSASJ5cycvUCMwDQYJKoZIhvcNAQELBQADggEBAJQ/FAbIBkXF
AkfSKWlJISTKowXmE0STjadhO3Q7NdfYQ9BnoozHdEr7I/v+r6lf3SkHJDQ+Vs2k
AHP2awPtziE70G9lWbyKDMeJtyM6k8l9PMAmcMVlXbdNyPiUgkpM1Vg31dZTIgJ/
RmpMiimcaSEtzJt7A7cWi+jkYc+lWNQ1EK73CKK6m7MqJiU/djjeyRb0rO7+YwLr
8p3+tf4rv2UM4gQ5b+TxACawAC+16r4ZJa9AO611teB8B/TztWSnnOl30W8ayfqp
PDPIWfODr5kFS9lVbRCXclD7Bqq7IEzXxSBKKgdszDvVJMjUNsRQiecaQ0yXx/Ai
Bd5OWdX5les=
-----END CERTIFICATE-----
subject=CN = *.genunix.com
issuer=C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
---
No client certificate CA names sent
Peer signing digest: SHA512
Peer signature type: RSA
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 3414 bytes and written 414 bytes
Verification: OK
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID:
C267C4D567384E4F4F43E100AF0AC05674118581C3F06B599436F49F9CCA3969
Session-ID-ctx:
Master-Key:
2E4E35B2B65B5A708CBD957680851B3217E121D570F7EBEF987E9BBE402660EC9DF8C7219BE30FBEFE5DF819A4F66471
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - 17 68 c9 86 d7 75 0d 7b-2b 76 fd 64 bd c5 19 9b
.h...u.{+v.d....
0010 - 9a 09 9c d4 6c 30 e7 22-97 2b c6 c7 cc 6f 4d bc
....l0.".+...oM.
0020 - dd 6b 3e 7e f5 8d 1c 4a-97 97 14 b3 e7 ba a9 56
.k>~...J.......V
0030 - c9 4a a4 2c f9 85 15 cc-db 7a 1a 0d 92 df 2f c0
.J.,.....z..../.
0040 - 0e e5 29 57 71 56 aa 5f-84 22 51 a4 4f 4d 00 3e
..)WqV._."Q.OM.>
0050 - cd 8f 48 85 76 c6 7c a9-46 1f e3 25 15 3b 8b 35
..H.v.|.F..%.;.5
0060 - 56 14 f0 ed d4 6d ba 3a-a7 ac ad 8b d9 15 6a a5
V....m.:......j.
0070 - 7e fd e6 46 11 f8 03 49-c7 f9 f6 d4 22 9c 4a f7
~..F...I....".J.
0080 - 52 ae 56 9a 3f 5e 69 41-57 13 ce d1 a6 c5 5f 83
R.V.?^iAW....._.
0090 - 52 c5 1c 0c 89 7d 71 d8-7f b3 c8 99 bc aa cf 49
R....}q........I
00a0 - b8 c8 7c f2 8e 63 57 6c-20 2c e8 99 c2 55 43 ab ..|..cWl
,...UC.
00b0 - 78 d6 da 4f a0 22 3e e8-d5 58 1c 2e 38 f1 de 7d
x..O.">..X..8..}
00c0 - 20 1b ee 41 18 1f 8a 4e-dc 17 cd 90 c2 2b c4 af
..A...N.....+..
00d0 - d5 dc 45 ca 37 4d 21 db-84 fb 04 24 55 6c 45 a2
..E.7M!....$UlE.
Start Time: 1539558601
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: yes
---
DONE
$
Stuff the cert into /tmp/foo_cert
$ openssl s_client -showcerts -connect node000.genunix.com:443 <
/dev/null 2>&1
CONNECTED(00000005)
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify return:1
depth=0 CN = *.genunix.com
verify return:1
---
Certificate chain
0 s:CN = *.genunix.com
i:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
-----BEGIN CERTIFICATE-----
MIIGBDCCBOygAwIBAgISA5BIQo7nEOdRweyW41WwX633MA0GCSqGSIb3DQEBCwUA
MEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQD
ExpMZXQncyBFbmNyeXB0IEF1dGhvcml0eSBYMzAeFw0xODA4MDQwMTU2MDZaFw0x
ODExMDIwMTU2MDZaMBgxFjAUBgNVBAMMDSouZ2VudW5peC5jb20wggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDOi3zn/l9/7shHNxXF2aUlv1Cy+lze/QFE
enan5hjsv52lCmiibZlwf0/3M8uQCazhaznHVMYiaBX5h3vAhR6/t47ckMlBows8
X4AP9PvvAR+zdS2EFWQ+bwAGMwuD/q7ZDoT0tyV6KIS7W9xZjd9SVleTyIAFH/rN
WRJxq80jJRpVX3gBdN8crM/rxgp98PJYorfCrF7EeDdGqRrzO/Q3BueCuU51a8kJ
Idbh7uIwUcyzPNdNMI7IJy2TxnKbb+ocg03ounWa42VBnfkeK1GM+t1r62zWyHs1
R9CetTpnmKNUWInZaHb142tjz/ZHxWpvz6wWLiDAUg9hokDI1Ld5AgMBAAGjggMU
MIIDEDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUF
BwMCMAwGA1UdEwEB/wQCMAAwHQYDVR0OBBYEFCCTnlBN2NePVn8eZBqdjyfC7rEM
MB8GA1UdIwQYMBaAFKhKamMEfd265tE5t6ZFZe/zqOyhMG8GCCsGAQUFBwEBBGMw
YTAuBggrBgEFBQcwAYYiaHR0cDovL29jc3AuaW50LXgzLmxldHNlbmNyeXB0Lm9y
ZzAvBggrBgEFBQcwAoYjaHR0cDovL2NlcnQuaW50LXgzLmxldHNlbmNyeXB0Lm9y
Zy8wGAYDVR0RBBEwD4INKi5nZW51bml4LmNvbTCB/gYDVR0gBIH2MIHzMAgGBmeB
DAECATCB5gYLKwYBBAGC3xMBAQEwgdYwJgYIKwYBBQUHAgEWGmh0dHA6Ly9jcHMu
bGV0c2VuY3J5cHQub3JnMIGrBggrBgEFBQcCAjCBngyBm1RoaXMgQ2VydGlmaWNh
dGUgbWF5IG9ubHkgYmUgcmVsaWVkIHVwb24gYnkgUmVseWluZyBQYXJ0aWVzIGFu
ZCBvbmx5IGluIGFjY29yZGFuY2Ugd2l0aCB0aGUgQ2VydGlmaWNhdGUgUG9saWN5
IGZvdW5kIGF0IGh0dHBzOi8vbGV0c2VuY3J5cHQub3JnL3JlcG9zaXRvcnkvMIIB
AwYKKwYBBAHWeQIEAgSB9ASB8QDvAHUA23Sv7ssp7LH+yj5xbSzluaq7NveEcYPH
XZ1PN7Yfv2QAAAFlAt0Q+gAABAMARjBEAiA+t4J1uZItOOTamCF9XsE+9S2hPpNN
bCsqHcn42p8b5AIgVi5jlTH5bSjiBkweb/nRExf6PpFZhvrb20hojYweFWwAdgAp
PFGWVMg5ZbqqUPxYB9S3b79Yeily3KTDDPTlRUf0eAAAAWUC3REOAAAEAwBHMEUC
IHd8ktNpgmeQkZQ9y+3I0o8IKJKyu9VkZ065or7lZSkIAiEA5t7ThHkcqY9QPPul
wsvQrCeMlgYfjNTSASJ5cycvUCMwDQYJKoZIhvcNAQELBQADggEBAJQ/FAbIBkXF
AkfSKWlJISTKowXmE0STjadhO3Q7NdfYQ9BnoozHdEr7I/v+r6lf3SkHJDQ+Vs2k
AHP2awPtziE70G9lWbyKDMeJtyM6k8l9PMAmcMVlXbdNyPiUgkpM1Vg31dZTIgJ/
RmpMiimcaSEtzJt7A7cWi+jkYc+lWNQ1EK73CKK6m7MqJiU/djjeyRb0rO7+YwLr
8p3+tf4rv2UM4gQ5b+TxACawAC+16r4ZJa9AO611teB8B/TztWSnnOl30W8ayfqp
PDPIWfODr5kFS9lVbRCXclD7Bqq7IEzXxSBKKgdszDvVJMjUNsRQiecaQ0yXx/Ai
Bd5OWdX5les=
-----END CERTIFICATE-----
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
-----BEGIN CERTIFICATE-----
MIIEkjCCA3qgAwIBAgIQCgFBQgAAAVOFc2oLheynCDANBgkqhkiG9w0BAQsFADA/
MSQwIgYDVQQKExtEaWdpdGFsIFNpZ25hdHVyZSBUcnVzdCBDby4xFzAVBgNVBAMT
DkRTVCBSb290IENBIFgzMB4XDTE2MDMxNzE2NDA0NloXDTIxMDMxNzE2NDA0Nlow
SjELMAkGA1UEBhMCVVMxFjAUBgNVBAoTDUxldCdzIEVuY3J5cHQxIzAhBgNVBAMT
GkxldCdzIEVuY3J5cHQgQXV0aG9yaXR5IFgzMIIBIjANBgkqhkiG9w0BAQEFAAOC
AQ8AMIIBCgKCAQEAnNMM8FrlLke3cl03g7NoYzDq1zUmGSXhvb418XCSL7e4S0EF
q6meNQhY7LEqxGiHC6PjdeTm86dicbp5gWAf15Gan/PQeGdxyGkOlZHP/uaZ6WA8
SMx+yk13EiSdRxta67nsHjcAHJyse6cF6s5K671B5TaYucv9bTyWaN8jKkKQDIZ0
Z8h/pZq4UmEUEz9l6YKHy9v6Dlb2honzhT+Xhq+w3Brvaw2VFn3EK6BlspkENnWA
a6xK8xuQSXgvopZPKiAlKQTGdMDQMc2PMTiVFrqoM7hD8bEfwzB/onkxEz0tNvjj
/PIzark5McWvxI0NHWQWM6r6hCm21AvA2H3DkwIDAQABo4IBfTCCAXkwEgYDVR0T
AQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwfwYIKwYBBQUHAQEEczBxMDIG
CCsGAQUFBzABhiZodHRwOi8vaXNyZy50cnVzdGlkLm9jc3AuaWRlbnRydXN0LmNv
bTA7BggrBgEFBQcwAoYvaHR0cDovL2FwcHMuaWRlbnRydXN0LmNvbS9yb290cy9k
c3Ryb290Y2F4My5wN2MwHwYDVR0jBBgwFoAUxKexpHsscfrb4UuQdf/EFWCFiRAw
VAYDVR0gBE0wSzAIBgZngQwBAgEwPwYLKwYBBAGC3xMBAQEwMDAuBggrBgEFBQcC
ARYiaHR0cDovL2Nwcy5yb290LXgxLmxldHNlbmNyeXB0Lm9yZzA8BgNVHR8ENTAz
MDGgL6AthitodHRwOi8vY3JsLmlkZW50cnVzdC5jb20vRFNUUk9PVENBWDNDUkwu
Y3JsMB0GA1UdDgQWBBSoSmpjBH3duubRObemRWXv86jsoTANBgkqhkiG9w0BAQsF
AAOCAQEA3TPXEfNjWDjdGBX7CVW+dla5cEilaUcne8IkCJLxWh9KEik3JHRRHGJo
uM2VcGfl96S8TihRzZvoroed6ti6WqEBmtzw3Wodatg+VyOeph4EYpr/1wXKtx8/
wApIvJSwtmVi4MFU5aMqrSDE6ea73Mj2tcMyo5jMd6jmeWUHK8so/joWUoHOUgwu
X4Po1QYz+3dszkDqMp4fklxBwXRsW10KXzPMTZ+sOPAveyxindmjkW8lGy+QsRlG
PfZ+G6Z6h7mjem0Y+iWlkYcV4PIWL1iwBi8saCbGS5jN2p8M+X+Q7UNKEkROb3N6
KOqkqm57TH2H3eDJAkSnh6/DNFu0Qg==
-----END CERTIFICATE-----
---
Server certificate
subject=CN = *.genunix.com
issuer=C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
---
No client certificate CA names sent
Peer signing digest: SHA512
Peer signature type: RSA
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 3414 bytes and written 414 bytes
Verification: OK
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID:
8B9486CA5C5B5ACBB01413C6B441031CDC6596C638CED1D1050630B73B493276
Session-ID-ctx:
Master-Key:
3724378CD3C231BDE6C1AAA15C7DCA53180F6F16EF1B1A52BB6B831D29E1BE6240B64E7A781B6393EB813B68685EE369
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - 17 68 c9 86 d7 75 0d 7b-2b 76 fd 64 bd c5 19 9b
.h...u.{+v.d....
0010 - 4a 40 7b 57 c3 db 64 37-15 a1 ef 25 95 99 8b bc
J@{W..d7...%....
0020 - 8f 49 b1 7a dc 58 74 72-2e 96 fd 05 23 01 05 07
.I.z.Xtr....#...
0030 - 29 76 e5 92 63 28 c0 a1-65 46 83 dd 3f 2d bb b8
)v..c(..eF..?-..
0040 - 2f 43 b9 52 80 e7 b0 0f-16 2b 75 ab 3f 5f be 3e
/C.R.....+u.?_.>
0050 - d5 b8 19 0b 45 10 13 e9-7e f4 53 92 61 e9 70 9d
....E...~.S.a.p.
0060 - bc 5f 8a 28 70 68 b6 3c-fd 8a be e1 d8 6a fb 0d
._.(ph.<.....j..
0070 - 4c 58 70 fe 76 3b db ad-03 be d4 fa 9f b6 71 76
LXp.v;........qv
0080 - 15 ac 62 f7 0f a2 f3 bd-a5 7f 6a 5a fe 44 2c 48
..b.......jZ.D,H
0090 - c9 b6 99 cd 32 a5 58 a9-46 89 4c 6b dc 8d 9b e8
....2.X.F.Lk....
00a0 - 07 55 34 a2 b4 f4 81 13-a7 4e 2e 4c e1 b3 35 b3
.U4......N.L..5.
00b0 - 37 ed 7c a6 d3 94 8c 12-94 22 89 12 46 26 20 19
7.|......"..F& .
00c0 - c8 e4 bb 75 41 aa 54 ef-49 db 29 e2 06 4a 37 be
...uA.T.I.)..J7.
00d0 - 29 75 ce ea b0 22 33 d8-d4 17 48 fc 1e 94 d5 c7
)u..."3...H.....
Start Time: 1539558661
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: yes
---
DONE
$
Stuff the chain bits into /tmp/foo_chain
Do the goodness OCSP responder staple check :
$ openssl x509 -noout -ocsp_uri -in /tmp/foo_cert
http://ocsp.int-x3.letsencrypt.org
$
$ openssl x509 -text -noout -in /tmp/foo_cert
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
03:90:48:42:8e:e7:10:e7:51:c1:ec:96:e3:55:b0:5f:ad:f7
Signature Algorithm: sha256WithRSAEncryption
Issuer: C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
Validity
Not Before: Aug 4 01:56:06 2018 GMT
Not After : Nov 2 01:56:06 2018 GMT
Subject: CN = *.genunix.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (2048 bit)
Modulus:
00:ce:8b:7c:e7:fe:5f:7f:ee:c8:47:37:15:c5:d9:
a5:25:bf:50:b2:fa:5c:de:fd:01:44:7a:76:a7:e6:
18:ec:bf:9d:a5:0a:68:a2:6d:99:70:7f:4f:f7:33:
cb:90:09:ac:e1:6b:39:c7:54:c6:22:68:15:f9:87:
7b:c0:85:1e:bf:b7:8e:dc:90:c9:41:a3:0b:3c:5f:
80:0f:f4:fb:ef:01:1f:b3:75:2d:84:15:64:3e:6f:
00:06:33:0b:83:fe:ae:d9:0e:84:f4:b7:25:7a:28:
84:bb:5b:dc:59:8d:df:52:56:57:93:c8:80:05:1f:
fa:cd:59:12:71:ab:cd:23:25:1a:55:5f:78:01:74:
df:1c:ac:cf:eb:c6:0a:7d:f0:f2:58:a2:b7:c2:ac:
5e:c4:78:37:46:a9:1a:f3:3b:f4:37:06:e7:82:b9:
4e:75:6b:c9:09:21:d6:e1:ee:e2:30:51:cc:b3:3c:
d7:4d:30:8e:c8:27:2d:93:c6:72:9b:6f:ea:1c:83:
4d:e8:ba:75:9a:e3:65:41:9d:f9:1e:2b:51:8c:fa:
dd:6b:eb:6c:d6:c8:7b:35:47:d0:9e:b5:3a:67:98:
a3:54:58:89:d9:68:76:f5:e3:6b:63:cf:f6:47:c5:
6a:6f:cf:ac:16:2e:20:c0:52:0f:61:a2:40:c8:d4:
b7:79
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client
Authentication
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Subject Key Identifier:
20:93:9E:50:4D:D8:D7:8F:56:7F:1E:64:1A:9D:8F:27:C2:EE:B1:0C
X509v3 Authority Key Identifier:
keyid:A8:4A:6A:63:04:7D:DD:BA:E6:D1:39:B7:A6:45:65:EF:F3:A8:EC:A1
Authority Information Access:
OCSP - URI:http://ocsp.int-x3.letsencrypt.org
CA Issuers - URI:http://cert.int-x3.letsencrypt.org/
X509v3 Subject Alternative Name:
DNS:*.genunix.com
X509v3 Certificate Policies:
Policy: 2.23.140.1.2.1
Policy: 1.3.6.1.4.1.44947.1.1.1
CPS: http://cps.letsencrypt.org
User Notice:
Explicit Text: This Certificate may only be relied
upon by Relying Parties and only in accordance with the Certificate
Policy found at https://letsencrypt.org/repository/
CT Precertificate SCTs:
Signed Certificate Timestamp:
Version : v1 (0x0)
Log ID :
DB:74:AF:EE:CB:29:EC:B1:FE:CA:3E:71:6D:2C:E5:B9:
AA:BB:36:F7:84:71:83:C7:5D:9D:4F:37:B6:1F:BF:64
Timestamp : Aug 4 02:56:06.906 2018 GMT
Extensions: none
Signature : ecdsa-with-SHA256
30:44:02:20:3E:B7:82:75:B9:92:2D:38:E4:DA:98:21:
7D:5E:C1:3E:F5:2D:A1:3E:93:4D:6C:2B:2A:1D:C9:F8:
DA:9F:1B:E4:02:20:56:2E:63:95:31:F9:6D:28:E2:06:
4C:1E:6F:F9:D1:13:17:FA:3E:91:59:86:FA:DB:DB:48:
68:8D:8C:1E:15:6C
Signed Certificate Timestamp:
Version : v1 (0x0)
Log ID :
29:3C:51:96:54:C8:39:65:BA:AA:50:FC:58:07:D4:B7:
6F:BF:58:7A:29:72:DC:A4:C3:0C:F4:E5:45:47:F4:78
Timestamp : Aug 4 02:56:06.926 2018 GMT
Extensions: none
Signature : ecdsa-with-SHA256
30:45:02:20:77:7C:92:D3:69:82:67:90:91:94:3D:CB:
ED:C8:D2:8F:08:28:92:B2:BB:D5:64:67:4E:B9:A2:BE:
E5:65:29:08:02:21:00:E6:DE:D3:84:79:1C:A9:8F:50:
3C:FB:A5:C2:CB:D0:AC:27:8C:96:06:1F:8C:D4:D2:01:
22:79:73:27:2F:50:23
Signature Algorithm: sha256WithRSAEncryption
94:3f:14:06:c8:06:45:c5:02:47:d2:29:69:49:21:24:ca:a3:
05:e6:13:44:93:8d:a7:61:3b:74:3b:35:d7:d8:43:d0:67:a2:
8c:c7:74:4a:fb:23:fb:fe:af:a9:5f:dd:29:07:24:34:3e:56:
cd:a4:00:73:f6:6b:03:ed:ce:21:3b:d0:6f:65:59:bc:8a:0c:
c7:89:b7:23:3a:93:c9:7d:3c:c0:26:70:c5:65:5d:b7:4d:c8:
f8:94:82:4a:4c:d5:58:37:d5:d6:53:22:02:7f:46:6a:4c:8a:
29:9c:69:21:2d:cc:9b:7b:03:b7:16:8b:e8:e4:61:cf:a5:58:
d4:35:10:ae:f7:08:a2:ba:9b:b3:2a:26:25:3f:76:38:de:c9:
16:f4:ac:ee:fe:63:02:eb:f2:9d:fe:b5:fe:2b:bf:65:0c:e2:
04:39:6f:e4:f1:00:26:b0:00:2f:b5:ea:be:19:25:af:40:3b:
ad:75:b5:e0:7c:07:f4:f3:b5:64:a7:9c:e9:77:d1:6f:1a:c9:
fa:a9:3c:33:c8:59:f3:83:af:99:05:4b:d9:55:6d:10:97:72:
50:fb:06:aa:bb:20:4c:d7:c5:20:4a:2a:07:6c:cc:3b:d5:24:
c8:d4:36:c4:50:89:e7:1a:43:4c:97:c7:f0:22:05:de:4e:59:
d5:f9:95:eb
$
ta da ...
$ openssl ocsp -issuer /tmp/foo_chain -cert /tmp/foo_cert -text -url
http://ocsp.int-x3.letsencrypt.org
OCSP Request Data:
Version: 1 (0x0)
Requestor List:
Certificate ID:
Hash Algorithm: sha1
Issuer Name Hash: 7EE66AE7729AB3FCF8A220646C16A12D6071085D
Issuer Key Hash: A84A6A63047DDDBAE6D139B7A64565EFF3A8ECA1
Serial Number: 039048428EE710E751C1EC96E355B05FADF7
Request Extensions:
OCSP Nonce:
0410AF283079082966EF04E8805C8D9215EB
OCSP Response Data:
OCSP Response Status: successful (0x0)
Response Type: Basic OCSP Response
Version: 1 (0x0)
Responder Id: C = US, O = Let's Encrypt, CN = Let's Encrypt
Authority X3
Produced At: Oct 12 02:56:00 2018 GMT
Responses:
Certificate ID:
Hash Algorithm: sha1
Issuer Name Hash: 7EE66AE7729AB3FCF8A220646C16A12D6071085D
Issuer Key Hash: A84A6A63047DDDBAE6D139B7A64565EFF3A8ECA1
Serial Number: 039048428EE710E751C1EC96E355B05FADF7
Cert Status: good
This Update: Oct 12 02:00:00 2018 GMT
Next Update: Oct 19 02:00:00 2018 GMT
Signature Algorithm: sha256WithRSAEncryption
76:f4:7f:ff:4a:c5:26:c2:60:88:fe:ef:90:dd:c7:0a:39:fd:
d0:df:fe:17:4b:71:78:08:60:e0:ee:14:4b:98:91:ef:77:59:
81:51:ee:cc:b6:16:99:92:7d:98:64:e2:a7:be:f2:cb:24:61:
47:67:0c:62:2c:06:95:4b:73:34:0c:7a:ce:ce:1c:27:85:14:
97:f7:2e:76:3e:21:8b:83:ab:29:1f:55:48:25:f4:61:6a:d8:
bf:65:10:90:71:04:10:45:4d:9a:37:84:02:9e:eb:06:45:3f:
85:4c:e4:a4:b6:3f:54:fa:4d:4b:9e:d4:8f:1b:44:4f:fb:6c:
e3:18:11:ba:3c:e1:21:64:97:4b:4a:28:d7:c5:b1:b3:46:fe:
36:99:da:da:aa:e4:32:57:a1:14:d5:54:b9:6d:e4:49:59:a2:
77:d4:87:97:95:8d:e6:7c:5b:64:db:60:ab:3e:e3:a7:a6:bc:
00:0e:b8:dd:0c:42:a0:18:f8:d5:73:16:80:50:3c:b3:24:d0:
01:da:3d:09:29:4e:93:d7:81:27:91:39:9c:67:99:53:d4:5f:
ab:6a:42:67:1e:ca:9d:4c:40:a7:f8:71:e4:bf:43:e8:a0:20:
62:9c:d5:25:16:8a:41:f5:70:85:c4:e4:45:9d:b6:95:4f:4f:
79:3f:84:53
WARNING: no nonce in response
Response verify OK
/tmp/foo_cert: good
This Update: Oct 12 02:00:00 2018 GMT
Next Update: Oct 19 02:00:00 2018 GMT
$
$
I am sure that OpenSSL 1.1.1 would have no issues with www.tls13.net but
anything less won't grok that at all.
Dennis
Re: svn commit: r1843478 - /httpd/test/framework/trunk/t/ssl/ocsp.t
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
Dennis, just to confirm ... is this build ocsp enabled, or entirely absent
and yet presenting the ocsp help in absence of the feature?
On Sun, Oct 14, 2018 at 4:38 PM Dennis Clarke <dc...@blastwave.org> wrote:
> On 10/14/2018 05:14 PM, Rainer Jung wrote:
> > Am 14.10.2018 um 22:58 schrieb William A Rowe Jr:
> >> On Sun, Oct 14, 2018 at 3:50 PM Rainer Jung <rainer.jung@kippdata.de
> >> <ma...@kippdata.de>> wrote:
> >>
> >>
> >> And Jim already set "With 1.1.1, both return 1, but so what, we know
> >> that it has oscp."
> >>
> >>
> >> That, of course, is nonsense.
> >>
> >> OpenSSL is malleable... with numerous no-{feature} choice, we really
> >> shouldn't
> >> presume presence of features by OpenSSL version. Otherwise, why wouldn't
> >> we simply use a regex against `openssl version`?
> >
> > Agreed, looking at the code it seems that starting with 1.1.0 (I only
> > checked 1.1.0i) ocsp can be disabled with no-ocsp.
> >
>
> As a red herring that illustrates how oddball the situation could get :
>
> $ /usr/sfw/bin/openssl version 2>&1 | cut -f1 -d\(
> OpenSSL 0.9.7d 17 Mar 2004
>
> $ /usr/sfw/bin/openssl ocsp > /dev/null
> OCSP utility
> Usage ocsp [options]
> where options are
> -out file output filename
> -issuer file issuer certificate
> -cert file certificate to check
> -serial n serial number to check
> -signer file certificate to sign OCSP request with
> -signkey file private key to sign OCSP request with
> -sign_other file additional certificates to include in signed request
> -no_certs don't include any certificates in signed request
> -req_text print text form of request
> -resp_text print text form of response
> -text print text form of request and response
> -reqout file write DER encoded OCSP request to "file"
> -respout file write DER encoded OCSP reponse to "file"
> -reqin file read DER encoded OCSP request from "file"
> -respin file read DER encoded OCSP reponse from "file"
> -nonce add OCSP nonce to request
> -no_nonce don't add OCSP nonce to request
> -url URL OCSP responder URL
> -host host:n send OCSP request to host on port n
> -path path to use in OCSP request
> -CApath dir trusted certificates directory
> -CAfile file trusted certificates file
> -VAfile file validator certificates file
> -validity_period n maximum validity discrepancy in seconds
> -status_age n maximum status age in seconds
> -noverify don't verify response at all
> -verify_other file additional certificates to search for signer
> -trust_other don't verify additional certificates
> -no_intern don't search certificates contained in response for
> signer
> -no_signature_verify don't check signature on response
> -no_cert_verify don't check signing certificate
> -no_chain don't chain verify response
> -no_cert_checks don't do additional checks on signing certificate
> -port num port to run responder on
> -index file certificate status index file
> -CA file CA certificate
> -rsigner file responder certificate to sign responses with
> -rkey file responder key to sign responses with
> -rother file other certificates to include in response
> -resp_no_certs don't include any certificates in response
> -nmin n number of minutes before next update
> -ndays n number of days before next update
> -resp_key_id identify reponse by signing certificate key ID
> -nrequest n number of requests to accept (default unlimited)
> Segmentation Fault(coredump)
> $
>
> So, the situation can get out of hand quickly.
>
> Dennis
>
> ps: I am on the sidelines reading *all* of this and wondering ...
>
Re: svn commit: r1843478 - /httpd/test/framework/trunk/t/ssl/ocsp.t
Posted by Dennis Clarke <dc...@blastwave.org>.
On 10/14/2018 05:14 PM, Rainer Jung wrote:
> Am 14.10.2018 um 22:58 schrieb William A Rowe Jr:
>> On Sun, Oct 14, 2018 at 3:50 PM Rainer Jung <rainer.jung@kippdata.de
>> <ma...@kippdata.de>> wrote:
>>
>>
>> And Jim already set "With 1.1.1, both return 1, but so what, we know
>> that it has oscp."
>>
>>
>> That, of course, is nonsense.
>>
>> OpenSSL is malleable... with numerous no-{feature} choice, we really
>> shouldn't
>> presume presence of features by OpenSSL version. Otherwise, why wouldn't
>> we simply use a regex against `openssl version`?
>
> Agreed, looking at the code it seems that starting with 1.1.0 (I only
> checked 1.1.0i) ocsp can be disabled with no-ocsp.
>
As a red herring that illustrates how oddball the situation could get :
$ /usr/sfw/bin/openssl version 2>&1 | cut -f1 -d\(
OpenSSL 0.9.7d 17 Mar 2004
$ /usr/sfw/bin/openssl ocsp > /dev/null
OCSP utility
Usage ocsp [options]
where options are
-out file output filename
-issuer file issuer certificate
-cert file certificate to check
-serial n serial number to check
-signer file certificate to sign OCSP request with
-signkey file private key to sign OCSP request with
-sign_other file additional certificates to include in signed request
-no_certs don't include any certificates in signed request
-req_text print text form of request
-resp_text print text form of response
-text print text form of request and response
-reqout file write DER encoded OCSP request to "file"
-respout file write DER encoded OCSP reponse to "file"
-reqin file read DER encoded OCSP request from "file"
-respin file read DER encoded OCSP reponse from "file"
-nonce add OCSP nonce to request
-no_nonce don't add OCSP nonce to request
-url URL OCSP responder URL
-host host:n send OCSP request to host on port n
-path path to use in OCSP request
-CApath dir trusted certificates directory
-CAfile file trusted certificates file
-VAfile file validator certificates file
-validity_period n maximum validity discrepancy in seconds
-status_age n maximum status age in seconds
-noverify don't verify response at all
-verify_other file additional certificates to search for signer
-trust_other don't verify additional certificates
-no_intern don't search certificates contained in response for
signer
-no_signature_verify don't check signature on response
-no_cert_verify don't check signing certificate
-no_chain don't chain verify response
-no_cert_checks don't do additional checks on signing certificate
-port num port to run responder on
-index file certificate status index file
-CA file CA certificate
-rsigner file responder certificate to sign responses with
-rkey file responder key to sign responses with
-rother file other certificates to include in response
-resp_no_certs don't include any certificates in response
-nmin n number of minutes before next update
-ndays n number of days before next update
-resp_key_id identify reponse by signing certificate key ID
-nrequest n number of requests to accept (default unlimited)
Segmentation Fault(coredump)
$
So, the situation can get out of hand quickly.
Dennis
ps: I am on the sidelines reading *all* of this and wondering ...
Re: svn commit: r1843478 - /httpd/test/framework/trunk/t/ssl/ocsp.t
Posted by Rainer Jung <ra...@kippdata.de>.
Am 14.10.2018 um 22:58 schrieb William A Rowe Jr:
> On Sun, Oct 14, 2018 at 3:50 PM Rainer Jung <rainer.jung@kippdata.de
> <ma...@kippdata.de>> wrote:
>
>
> And Jim already set "With 1.1.1, both return 1, but so what, we know
> that it has oscp."
>
>
> That, of course, is nonsense.
>
> OpenSSL is malleable... with numerous no-{feature} choice, we really
> shouldn't
> presume presence of features by OpenSSL version. Otherwise, why wouldn't
> we simply use a regex against `openssl version`?
Agreed, looking at the code it seems that starting with 1.1.0 (I only
checked 1.1.0i) ocsp can be disabled with no-ocsp.
Regards,
Rainer
Re: svn commit: r1843478 - /httpd/test/framework/trunk/t/ssl/ocsp.t
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Sun, Oct 14, 2018 at 3:50 PM Rainer Jung <ra...@kippdata.de> wrote:
>
> And Jim already set "With 1.1.1, both return 1, but so what, we know
> that it has oscp."
>
That, of course, is nonsense.
OpenSSL is malleable... with numerous no-{feature} choice, we really
shouldn't
presume presence of features by OpenSSL version. Otherwise, why wouldn't
we simply use a regex against `openssl version`?
Re: svn commit: r1843478 - /httpd/test/framework/trunk/t/ssl/ocsp.t
Posted by Rainer Jung <ra...@kippdata.de>.
Am 14.10.2018 um 21:59 schrieb William A Rowe Jr:
> On Sun, Oct 14, 2018 at 8:32 AM Jim Jagielski <jim@jagunet.com
> <ma...@jagunet.com>> wrote:
>
> All we are checking is the error code. Nothing else.
>
> % openssl version
> OpenSSL 1.0.2p 14 Aug 2018
> % openssl ocsp 2>/dev/null
> % print $?
> 1
> % openssl foo 2>/dev/null
> % print $?
> 0
>
> With 1.1.1, both return 1, but so what, we know that it has oscp.
I can confirm this behavior for normal OpenSSL 1.0.2p.
> $ openssl ocsp >/dev/null
> ocsp: Use -help for summary.[wrowe@hub test-httpd]$ echo $?
> $ echo $?
> 1
> $ openssl xyz >/dev/null
> Invalid command 'xyz'; type "help" for a list.
> $ echo $?
> 1
> $ openssl version
> OpenSSL 1.1.0i-fips 14 Aug 2018
I can also confirm this behavior for normal OpenSSL 1.1.0i.
And Jim already set "With 1.1.1, both return 1, but so what, we know
that it has oscp."
> This doesn't tell us whether ocsp is compiled in.
> I have no idea which bastardization of the openssl command line tool you
> are using which returns success for bad verbs.
Please refrain from such wil guessing (bastardization).
So checking the status code seems OK for 1.0.2 and newerversions as well
(for different reasons), but it doesn't look understandable either
(because it only works for 1.1.0+ due to a change in behavior). If
Bill's suggestion "`$openssl ocsp -help` !~ /Usage:/" it would be easier
to understand.
> Complaining about /dev/null : orig code had this. Why was that OK?
But I think you (Jim) introduced /dev/null in an attempt to fix another
problem in r1832567.
> Never suggested it was OK.
I guess that's not what Jim meant, instead he might have asked why there
was no complaint when it was originally introduced. But i think that
doesn't lead us anywhere.
> Asking about finding potential *solutions* instead of throwing more
> darts at the wall. Why the emotive tone to a technical discussion?
Probably because it was unclear at that point whether there was a problem.
Regards,
Rainer
Re: svn commit: r1843478 - /httpd/test/framework/trunk/t/ssl/ocsp.t
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
Copy paste missed a stderr line;
$ openssl ocsp >/dev/null
ocsp: Use -help for summary.
$ echo $?
1
$ openssl xyz >/dev/null
Invalid command 'xyz'; type "help" for a list.
$ echo $?
1
$ openssl version
OpenSSL 1.1.0i-fips 14 Aug 2018
This is from
# dnf list openssl
Installed Packages
openssl.x86_64 1:1.1.0i-1.fc27
@updates
# cat /etc/redhat-release
Fedora release 27 (Twenty Seven)
Re: svn commit: r1843478 - /httpd/test/framework/trunk/t/ssl/ocsp.t
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Sun, Oct 14, 2018 at 8:32 AM Jim Jagielski <ji...@jagunet.com> wrote:
> All we are checking is the error code. Nothing else.
>
> % openssl version
> OpenSSL 1.0.2p 14 Aug 2018
> % openssl ocsp 2>/dev/null
> % print $?
> 1
> % openssl foo 2>/dev/null
> % print $?
> 0
>
> With 1.1.1, both return 1, but so what, we know that it has oscp.
>
$ openssl ocsp >/dev/null
ocsp: Use -help for summary.[wrowe@hub test-httpd]$ echo $?
$ echo $?
1
$ openssl xyz >/dev/null
Invalid command 'xyz'; type "help" for a list.
$ echo $?
1
$ openssl version
OpenSSL 1.1.0i-fips 14 Aug 2018
This doesn't tell us whether ocsp is compiled in.
I have no idea which bastardization of the openssl command line tool you
are using which returns success for bad verbs.
Complaining about /dev/null : orig code had this. Why was that OK?
>
Never suggested it was OK.
Asking about finding potential *solutions* instead of throwing more darts
at the wall. Why the emotive tone to a technical discussion?
Re: svn commit: r1843478 - /httpd/test/framework/trunk/t/ssl/ocsp.t
Posted by Jim Jagielski <ji...@jaguNET.com>.
All we are checking is the error code. Nothing else.
% openssl version
OpenSSL 1.0.2p 14 Aug 2018
% openssl ocsp 2>/dev/null
% print $?
1
% openssl foo 2>/dev/null
% print $?
0
With 1.1.1, both return 1, but so what, we know that it has oscp.
Complaining about /dev/null : orig code had this. Why was that OK?
> On Oct 13, 2018, at 2:35 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>
> On Wed, Oct 10, 2018 at 12:27 PM <jim@apache.org <ma...@apache.org>> wrote:
> Author: jim
> Date: Wed Oct 10 17:27:33 2018
> New Revision: 1843478
>
> URL: http://svn.apache.org/viewvc?rev=1843478&view=rev <http://svn.apache.org/viewvc?rev=1843478&view=rev>
> Log:
> Better method... just check return status
>
> Modified:
> httpd/test/framework/trunk/t/ssl/ocsp.t
>
> Modified: httpd/test/framework/trunk/t/ssl/ocsp.t
> URL: http://svn.apache.org/viewvc/httpd/test/framework/trunk/t/ssl/ocsp.t?rev=1843478&r1=1843477&r2=1843478&view=diff <http://svn.apache.org/viewvc/httpd/test/framework/trunk/t/ssl/ocsp.t?rev=1843478&r1=1843477&r2=1843478&view=diff>
> ==============================================================================
> --- httpd/test/framework/trunk/t/ssl/ocsp.t (original)
> +++ httpd/test/framework/trunk/t/ssl/ocsp.t Wed Oct 10 17:27:33 2018
> @@ -21,7 +21,7 @@ Apache::TestRequest::module('ssl_ocsp');
> # support in earlier versions without messing around with stderr
> my $openssl = Apache::TestSSLCA::openssl();
> if (!have_min_apache_version('2.4.26')
> - or `$openssl list-standard-commands 2>/dev/null` !~ /ocsp/) {
> + or system("$openssl ocsp 2>/dev/null") == 0) {
>
> On Windows, /dev/null is invalid (output target nul, eg NUL).
>
> On every platform this is an always-fail noop, since `openssl ocsp` always results in an error. Not enough arguments. You disabled this test on all environments, please revert.
>
> One test without extraneous stdout garbage might be to test ( `$openssl ocsp -help` !~ /Usage:/ ) ... in theory this would both succeed (success 0), eat stdout, and there should be no Usage: instructions if the ocsp verb doesn't exist.
>
> Thoughts?
>
>
Re: svn commit: r1843478 - /httpd/test/framework/trunk/t/ssl/ocsp.t
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Sat, Oct 13, 2018 at 1:35 PM William A Rowe Jr <wr...@rowe-clan.net>
wrote:
> On Wed, Oct 10, 2018 at 12:27 PM <ji...@apache.org> wrote:
>
>> Author: jim
>> Date: Wed Oct 10 17:27:33 2018
>> New Revision: 1843478
>>
>> URL: http://svn.apache.org/viewvc?rev=1843478&view=rev
>> Log:
>> Better method... just check return status
>>
>> Modified:
>> httpd/test/framework/trunk/t/ssl/ocsp.t
>>
>> Modified: httpd/test/framework/trunk/t/ssl/ocsp.t
>> URL:
>> http://svn.apache.org/viewvc/httpd/test/framework/trunk/t/ssl/ocsp.t?rev=1843478&r1=1843477&r2=1843478&view=diff
>>
>> ==============================================================================
>> --- httpd/test/framework/trunk/t/ssl/ocsp.t (original)
>> +++ httpd/test/framework/trunk/t/ssl/ocsp.t Wed Oct 10 17:27:33 2018
>> @@ -21,7 +21,7 @@ Apache::TestRequest::module('ssl_ocsp');
>> # support in earlier versions without messing around with stderr
>> my $openssl = Apache::TestSSLCA::openssl();
>> if (!have_min_apache_version('2.4.26')
>> - or `$openssl list-standard-commands 2>/dev/null` !~ /ocsp/) {
>> + or system("$openssl ocsp 2>/dev/null") == 0) {
>>
>
> On Windows, /dev/null is invalid (output target nul, eg NUL).
>
> On every platform this is an always-fail noop, since `openssl ocsp` always
> results in an error. Not enough arguments. You disabled this test on all
> environments, please revert.
>
> One test without extraneous stdout garbage might be to test ( `$openssl
> ocsp -help` !~ /Usage:/ ) ... in theory this would both succeed (success
> 0), eat stdout, and there should be no Usage: instructions if the ocsp verb
> doesn't exist.
>
e.g.
$ openssl xyz -help
Invalid command 'xyz'; type "help" for a list.
$ echo $?
1
$ openssl ocsp -help
Usage: ocsp [options]
Valid options are:
-help Display this summary
-out outfile Output filename
[...]
$ echo $?
0