On Mon, Sep 26, 2016 at 2:53 PM, Paul Wouters <[email protected]> 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 _______________________________________________ Swan mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan
