[Swan] Question/troubleshooting x509 w/ intermediate & root CA

[Bryan Harris]

On Mon, Sep 26, 2016 at 2:53 PM, Paul Wouters <paul at nohats.ca> wrote:
>
> On Mon, 26 Sep 2016, Bryan Harris wrote:
>
>> Sep 26 14:07:34 right pluto[7928]: | get_issuer_crl : looking for a CRL issued by CN=Sally Sub CA,O=Sally,C=US
>> Sep 26 14:07:34 right pluto[7928]: | missing or expired CRL
>> Sep 26 14:07:34 right pluto[7928]: | crl_strict: 0, ocsp: 0, ocsp_strict: 0
>> Sep 26 14:07:34 right pluto[7928]: | certificate is valid
>
>
> This should still trigger a CRL fetch though, and on the next pass it
> should work.


Hmm, for some reason I didn't notice that type of behavior.  But, we
are using RHEL 6 and so I wonder if version in use does not have the
latest features.  Or it could be that I haven't yet corrected all
mistakes in my commands yet, and something is causing these guys to
behave this way.

Yep, after reading the man page, if crlcheckinterval is not specified
then RHEL version of ipsec uses zero, which means it will never fetch
the CRLs.

So, I set to five seconds.  Now, when I do a full-restart and then
"ipse auto --up" this tunnel, whichever server is the OTHER side of
the tunnel successfully downloads the root CA CRL but not the Sub CA
CRL.  For some reason they get stuck trying to obtain the Sub CA CRL.
So they can get one but not the other.

Sep 26 17:49:08 left pluto[2299]: | Calling
/usr/libexec/ipsec/_import_crl to import CRL - url:
http://sally.super-secret-website.com/sally.crl, der size: 658
Sep 26 17:49:08 left pluto[2299]: | CRL helper exited with status: 0
Sep 26 17:49:08 left pluto[2299]: | CRL imported
Sep 26 17:49:12 left pluto[2299]: | processing connection "mytunnel"
Sep 26 17:49:24 left pluto[2299]: | processing connection "mytunnel"
Sep 26 17:49:24 left pluto[2299]: | processing connection "mytunnel"
Sep 26 17:49:24 left pluto[2299]: | processing connection "mytunnel"
Sep 26 17:49:24 left pluto[2299]: | processing connection "mytunnel"
Sep 26 17:49:24 left pluto[2299]: | processing connection "mytunnel"
Sep 26 17:49:24 left pluto[2299]: | processing connection "mytunnel"
Sep 26 17:49:24 left pluto[2299]: "mytunnel" #1: Main mode peer ID is
ID_DER_ASN1_DN: 'C=US, O=Sally, CN=right'
Sep 26 17:49:24 left pluto[2299]: | decoded CN=right,O=Sally,C=US
Sep 26 17:49:24 left pluto[2299]: | get_issuer_crl : looking for a CRL
issued by CN=Sally Sub CA,O=Sally,C=US
Sep 26 17:49:24 left pluto[2299]: | missing or expired CRL in strict
mode, failing pending update
Sep 26 17:49:24 left pluto[2299]: |   trusted_ca_nss called with
a=(empty) b=(empty)
Sep 26 17:49:24 left pluto[2299]: "mytunnel" #1: no RSA public key
known for 'C=US, O=Sally, CN=right'
Sep 26 17:49:24 left pluto[2299]: "mytunnel" #1: sending encrypted
notification INVALID_KEY_INFORMATION to 192.168.122.8:500

I see that it calls to import CRL on the first line above correctly.
But I never see it attempt the same function for the second CRL.
Instead of _import_crl it calls get_issuer_crl.  I have both Root+Sub
CAs + left/right cert in the NSS database on each side.  My pkcs12
command had an option something like -certfile <(cat sally1 sally2)
which imported both of them.

When I look into and inspect each certificate, here is what I find.
But it's what I expect to find.

certutil -L -n "Sally Root CA - Sally" -d sql:/etc/ipsec.d --> does
not show any CRLs
certutil -L -n "Sally Sub CA - Sally" -d sql:/etc/ipsec.d ---> reveals
the main CRL
certutil -L -n "right" -d sql:/etc/ipsec.d ---> reveals the secondary CRL

I thought this was correct, but perhaps I'm wrong?  I thought the CRL
inside a cert would indicate the issuers CRL to indicate any certs
revoked by said issuer.  So in the case of Sub CA, it would show me
the root's CRL.  And in the case of left/right, it would show me the
Sub CAs CRL.  So this all seems okay to me.

> There are some other X.509 related fixes too in git master that will be released in 3.19.

Ah I wonder, do you think these could be related to the issue I am
having where my pluto only retrieves the root CA's CRL and not the Sub
CA's CRL?

V/r,
Bryan