Can someone explain the ordering of CRL and OCSP checking to me?  I know support has explained this several times, and I thought I had this down, but I still have questions.

From my understanding, WebSEAL checks OCSP first using entries in AIA (Authority Information Access) if OCSP is enabled, then CRL (HTTP) specified in the order of the incoming certificate's CDP (Certificate Distribution Point), then LDAP CRL (if configured).  Is this accurate?  Is there a flow diagram that anyone has produced for how things are supposed to work?  I thought years ago L2 may have sent me something but I cannot find it years later.

I came across an environment where client certificates are being used to authenticate against the WebSEAL, however, the first CRL in the cert's CDP can not be reached by this environment.  However, the connection timeouts (as specified in the WebSEAL configuration, see below) are high on this environment, yet there is no slowness in authentication.  On a side note, this particular environment has OCSP disabled in the WebSEAL configuration, although the incoming certs do have an OCSP responder in their AIA.  However, I think the OCSP responders in the certs is irrelevant since OCSP is disabled on the WebSEAL.

Does WebSEAL check all the CRLs in the CDP in parallel, using the answer from the first one that responds?  I am curious why this lack of connectivity to this particular CRL is not causing authentication delays.  There is no a fast reset on the network for this connection, so the connection to that first CRL is a silent drop.  Now, if both HTTP CRLs are unavailable, then the authentication is delayed (as I have tested this on my lab).

WebSEAL utilizes the following entries under the [ssl] stanza to control timeout of checking the various OCSP and CRLs as specified in the cert's AIA and CDP.  For example's sake, let's say these values are all set to 20 seconds.  Hence, I would expect things would get hung up when checking that first CRL due to GSK_HTTP_CONNECT_TIMEOUT being 20 seconds.  But authentication is fast in this scenario with one HTTP CRL not being reachable.

• GSK_HTTP_CONNECT_TIMEOUT gsk-attr-name = numeric:336:<seconds>
• GSK_OCSP_TIMEOUT gsk-attr-name = number:318:<seconds>
• GSK_HTTP_CDP_TIMEOUT gsk-attr-name = numeric:319:<seconds>
• GSK_LDAP_SEARCH_TIMEOUT gsk-attr-name = number:340:<seconds>
• GSK_LDAP_CONNECT_TIMEOUT gsk-attr-name = number:343:<seconds>

Also, if WebSEAL does do the HTTP CRL checks in parallel, does it do the same for OCSP?  Or if one of the OCSP responders in a cert's AIA is unavailable, is this going to cause authentication delays waiting on timeouts to occur?

PS:  This environment is on containers, and I don't have administrator access to the container infrastructure and hence I cannot obtain a packet trace.  On the virtual appliances I would usually use packet traces to figure these types of flow questions out, although that wasn't a definite answer and more of an assumption when I saw certain behaviors.

Thanks for any thoughts!

Matt

For reference:  https://www.ibm.com/docs/en/sva/10.0.6?topic=webseal-certificate-revocation-lists

Can someone explain the ordering of CRL and OCSP checking to me?  I know support has explained this several times, and I thought I had this down, but I still have questions.

From my understanding, WebSEAL checks OCSP first using entries in AIA (Authority Information Access) if OCSP is enabled, then CRL (HTTP) specified in the order of the incoming certificate's CDP (Certificate Distribution Point), then LDAP CRL (if configured).  Is this accurate?  Is there a flow diagram that anyone has produced for how things are supposed to work?  I thought years ago L2 may have sent me something but I cannot find it years later.

I came across an environment where client certificates are being used to authenticate against the WebSEAL, however, the first CRL in the cert's CDP can not be reached by this environment.  However, the connection timeouts (as specified in the WebSEAL configuration, see below) are high on this environment, yet there is no slowness in authentication.  On a side note, this particular environment has OCSP disabled in the WebSEAL configuration, although the incoming certs do have an OCSP responder in their AIA.  However, I think the OCSP responders in the certs is irrelevant since OCSP is disabled on the WebSEAL.

Does WebSEAL check all the CRLs in the CDP in parallel, using the answer from the first one that responds?  I am curious why this lack of connectivity to this particular CRL is not causing authentication delays.  There is no a fast reset on the network for this connection, so the connection to that first CRL is a silent drop.  Now, if both HTTP CRLs are unavailable, then the authentication is delayed (as I have tested this on my lab).

WebSEAL utilizes the following entries under the [ssl] stanza to control timeout of checking the various OCSP and CRLs as specified in the cert's AIA and CDP.  For example's sake, let's say these values are all set to 20 seconds.  Hence, I would expect things would get hung up when checking that first CRL due to GSK_HTTP_CONNECT_TIMEOUT being 20 seconds.  But authentication is fast in this scenario with one HTTP CRL not being reachable.

• GSK_HTTP_CONNECT_TIMEOUT gsk-attr-name = numeric:336:<seconds>
• GSK_OCSP_TIMEOUT gsk-attr-name = number:318:<seconds>
• GSK_HTTP_CDP_TIMEOUT gsk-attr-name = numeric:319:<seconds>
• GSK_LDAP_SEARCH_TIMEOUT gsk-attr-name = number:340:<seconds>
• GSK_LDAP_CONNECT_TIMEOUT gsk-attr-name = number:343:<seconds>

Also, if WebSEAL does do the HTTP CRL checks in parallel, does it do the same for OCSP?  Or if one of the OCSP responders in a cert's AIA is unavailable, is this going to cause authentication delays waiting on timeouts to occur?

PS:  This environment is on containers, and I don't have administrator access to the container infrastructure and hence I cannot obtain a packet trace.  On the virtual appliances I would usually use packet traces to figure these types of flow questions out, although that wasn't a definite answer and more of an assumption when I saw certain behaviors.

Thanks for any thoughts!

Matt

For reference:  https://www.ibm.com/docs/en/sva/10.0.6?topic=webseal-certificate-revocation-lists

Scott, thanks for the reply and clarification on some points.

I am still puzzled why this one environment does not encounter authentication delays given the first HTTP CRL is unavailable and has a silent drop at the network (hence no RST returned and it will have to wait the full timeout period).

For example, given the cert info below (CDP and AIA), if httpcrl1.acme.org is unavailable, wouldn't we encounter an authentication delay waiting for the connect timeout to occur before httpcrl2.acme.org is tried?

[1]CRL Distribution Point
     Distribution Point Name:
          Full Name:
               URL=http://httpcrl1.acme.org/SomeCA/CRL1.crl
               URL=http://httpcrl2.acme.org/SomeCA/CRL1.crl
               Directory Address:
                    CN=CRL1
                    CN=SomeCA
                    OU=x509
                    O=ACME
                    C=us

[1]Authority Info Access
     Access Method=Certification Authority Issuer (1.3.6.1.5.5.7.48.2)
     Alternative Name:
          URL=http://httpcrl1.acme.org/x509/SomeCA.p7c
[2]Authority Info Access
     Access Method=Certification Authority Issuer (1.3.6.1.5.5.7.48.2)
     Alternative Name:
          URL=http://httpcrl2.acme.org/x509/SomeCA.p7c
[3]Authority Info Access
     Access Method=On-line Certificate Status Protocol (1.3.6.1.5.5.7.48.1)
     Alternative Name:
          URL=http://ocsp1.acme.org/responder
[4]Authority Info Access
     Access Method=On-line Certificate Status Protocol (1.3.6.1.5.5.7.48.1)
     Alternative Name:
          URL=http://ocsp2.acme.org/responder

Now, I took this cert and ran it through a lab on a virtual appliance configured the same as this other environment.  What I see is the following in a packet capture:

1. WebSEAL connects to LDAP CRL specified in WebSEAL config file [ssl] crl-ldap-server setting and gets answer for Intermediate CA of incoming cert
2. WebSEAL attempts to connect to httpcrl1.acme.org and query Intermediate CA CRL server and the connection is immediately reset (in this lab I can't simulate a slow failure)
3. WebSEAL connects to httpcrl2.acme.org and gets response for Intermediate CA of incoming cert
   
   
4. WebSEAL connects to LDAP CRL specified in WebSEAL config file and gets answer for incoming user cert CRL
5. WebSEAL attempts to connect to httpcrl1.acme.org and query for incoming user cert CRL and gets immediately reset
6. WebSEAL connects to httpcrl2.acme.org and gets response for user cert CRL
   
   
7. Session is established and user authenticated

One thing I forgot about is the cert is signed by an intermediate CA, so basically Root CA -> Intermediate CA -> User Cert.

WebSEAL checks the intermediate (signing) CA cert first.  The top level root cert doesn't have a CDP/AIA in this case, so nothing gets checked there.  This intermediate signing cert explains why when the timeout values are higher, as we would encounter more delay because we have to timeout on multiple checks.

However, what I don't understand is why the LDAP CRL is checked first, and what happens if httpcrl1.acme.org has a slow reset (unfortunately I cannot test that at the moment as I cannot think of a way on the virtual appliance to make httpcrl1.acme.org fail).  According to the ISVA documentation, the LDAP CRL should be checked last:

https://www.ibm.com/docs/en/sva/10.0.6?topic=webseal-certificate-revocation-lists

Also, why if we get an answer from that first LDAP CRL call (configured in the WebSEAL conf file, not on the cert CDP or AIA) do we continue onto checking the other CRLs?  Do we check each CRL to make sure there is not a revocation entry in any of them for the cert we are checking?

Thanks again,

Matt

Can someone explain the ordering of CRL and OCSP checking to me?  I know support has explained this several times, and I thought I had this down, but I still have questions.

From my understanding, WebSEAL checks OCSP first using entries in AIA (Authority Information Access) if OCSP is enabled, then CRL (HTTP) specified in the order of the incoming certificate's CDP (Certificate Distribution Point), then LDAP CRL (if configured).  Is this accurate?  Is there a flow diagram that anyone has produced for how things are supposed to work?  I thought years ago L2 may have sent me something but I cannot find it years later.

I came across an environment where client certificates are being used to authenticate against the WebSEAL, however, the first CRL in the cert's CDP can not be reached by this environment.  However, the connection timeouts (as specified in the WebSEAL configuration, see below) are high on this environment, yet there is no slowness in authentication.  On a side note, this particular environment has OCSP disabled in the WebSEAL configuration, although the incoming certs do have an OCSP responder in their AIA.  However, I think the OCSP responders in the certs is irrelevant since OCSP is disabled on the WebSEAL.

Does WebSEAL check all the CRLs in the CDP in parallel, using the answer from the first one that responds?  I am curious why this lack of connectivity to this particular CRL is not causing authentication delays.  There is no a fast reset on the network for this connection, so the connection to that first CRL is a silent drop.  Now, if both HTTP CRLs are unavailable, then the authentication is delayed (as I have tested this on my lab).

WebSEAL utilizes the following entries under the [ssl] stanza to control timeout of checking the various OCSP and CRLs as specified in the cert's AIA and CDP.  For example's sake, let's say these values are all set to 20 seconds.  Hence, I would expect things would get hung up when checking that first CRL due to GSK_HTTP_CONNECT_TIMEOUT being 20 seconds.  But authentication is fast in this scenario with one HTTP CRL not being reachable.

• GSK_HTTP_CONNECT_TIMEOUT gsk-attr-name = numeric:336:<seconds>
• GSK_OCSP_TIMEOUT gsk-attr-name = number:318:<seconds>
• GSK_HTTP_CDP_TIMEOUT gsk-attr-name = numeric:319:<seconds>
• GSK_LDAP_SEARCH_TIMEOUT gsk-attr-name = number:340:<seconds>
• GSK_LDAP_CONNECT_TIMEOUT gsk-attr-name = number:343:<seconds>

Also, if WebSEAL does do the HTTP CRL checks in parallel, does it do the same for OCSP?  Or if one of the OCSP responders in a cert's AIA is unavailable, is this going to cause authentication delays waiting on timeouts to occur?

PS:  This environment is on containers, and I don't have administrator access to the container infrastructure and hence I cannot obtain a packet trace.  On the virtual appliances I would usually use packet traces to figure these types of flow questions out, although that wasn't a definite answer and more of an assumption when I saw certain behaviors.

Thanks for any thoughts!

Matt

For reference:  https://www.ibm.com/docs/en/sva/10.0.6?topic=webseal-certificate-revocation-lists

Scott, thanks for the reply and clarification on some points.

I am still puzzled why this one environment does not encounter authentication delays given the first HTTP CRL is unavailable and has a silent drop at the network (hence no RST returned and it will have to wait the full timeout period).

For example, given the cert info below (CDP and AIA), if httpcrl1.acme.org is unavailable, wouldn't we encounter an authentication delay waiting for the connect timeout to occur before httpcrl2.acme.org is tried?

[1]CRL Distribution Point
     Distribution Point Name:
          Full Name:
               URL=http://httpcrl1.acme.org/SomeCA/CRL1.crl
               URL=http://httpcrl2.acme.org/SomeCA/CRL1.crl
               Directory Address:
                    CN=CRL1
                    CN=SomeCA
                    OU=x509
                    O=ACME
                    C=us

[1]Authority Info Access
     Access Method=Certification Authority Issuer (1.3.6.1.5.5.7.48.2)
     Alternative Name:
          URL=http://httpcrl1.acme.org/x509/SomeCA.p7c
[2]Authority Info Access
     Access Method=Certification Authority Issuer (1.3.6.1.5.5.7.48.2)
     Alternative Name:
          URL=http://httpcrl2.acme.org/x509/SomeCA.p7c
[3]Authority Info Access
     Access Method=On-line Certificate Status Protocol (1.3.6.1.5.5.7.48.1)
     Alternative Name:
          URL=http://ocsp1.acme.org/responder
[4]Authority Info Access
     Access Method=On-line Certificate Status Protocol (1.3.6.1.5.5.7.48.1)
     Alternative Name:
          URL=http://ocsp2.acme.org/responder

Now, I took this cert and ran it through a lab on a virtual appliance configured the same as this other environment.  What I see is the following in a packet capture:

1. WebSEAL connects to LDAP CRL specified in WebSEAL config file [ssl] crl-ldap-server setting and gets answer for Intermediate CA of incoming cert
2. WebSEAL attempts to connect to httpcrl1.acme.org and query Intermediate CA CRL server and the connection is immediately reset (in this lab I can't simulate a slow failure)
3. WebSEAL connects to httpcrl2.acme.org and gets response for Intermediate CA of incoming cert
   
   
4. WebSEAL connects to LDAP CRL specified in WebSEAL config file and gets answer for incoming user cert CRL
5. WebSEAL attempts to connect to httpcrl1.acme.org and query for incoming user cert CRL and gets immediately reset
6. WebSEAL connects to httpcrl2.acme.org and gets response for user cert CRL
   
   
7. Session is established and user authenticated

One thing I forgot about is the cert is signed by an intermediate CA, so basically Root CA -> Intermediate CA -> User Cert.

WebSEAL checks the intermediate (signing) CA cert first.  The top level root cert doesn't have a CDP/AIA in this case, so nothing gets checked there.  This intermediate signing cert explains why when the timeout values are higher, as we would encounter more delay because we have to timeout on multiple checks.

However, what I don't understand is why the LDAP CRL is checked first, and what happens if httpcrl1.acme.org has a slow reset (unfortunately I cannot test that at the moment as I cannot think of a way on the virtual appliance to make httpcrl1.acme.org fail).  According to the ISVA documentation, the LDAP CRL should be checked last:

https://www.ibm.com/docs/en/sva/10.0.6?topic=webseal-certificate-revocation-lists

Also, why if we get an answer from that first LDAP CRL call (configured in the WebSEAL conf file, not on the cert CDP or AIA) do we continue onto checking the other CRLs?  Do we check each CRL to make sure there is not a revocation entry in any of them for the cert we are checking?

Thanks again,

Matt

Can someone explain the ordering of CRL and OCSP checking to me?  I know support has explained this several times, and I thought I had this down, but I still have questions.

From my understanding, WebSEAL checks OCSP first using entries in AIA (Authority Information Access) if OCSP is enabled, then CRL (HTTP) specified in the order of the incoming certificate's CDP (Certificate Distribution Point), then LDAP CRL (if configured).  Is this accurate?  Is there a flow diagram that anyone has produced for how things are supposed to work?  I thought years ago L2 may have sent me something but I cannot find it years later.

I came across an environment where client certificates are being used to authenticate against the WebSEAL, however, the first CRL in the cert's CDP can not be reached by this environment.  However, the connection timeouts (as specified in the WebSEAL configuration, see below) are high on this environment, yet there is no slowness in authentication.  On a side note, this particular environment has OCSP disabled in the WebSEAL configuration, although the incoming certs do have an OCSP responder in their AIA.  However, I think the OCSP responders in the certs is irrelevant since OCSP is disabled on the WebSEAL.

Does WebSEAL check all the CRLs in the CDP in parallel, using the answer from the first one that responds?  I am curious why this lack of connectivity to this particular CRL is not causing authentication delays.  There is no a fast reset on the network for this connection, so the connection to that first CRL is a silent drop.  Now, if both HTTP CRLs are unavailable, then the authentication is delayed (as I have tested this on my lab).

WebSEAL utilizes the following entries under the [ssl] stanza to control timeout of checking the various OCSP and CRLs as specified in the cert's AIA and CDP.  For example's sake, let's say these values are all set to 20 seconds.  Hence, I would expect things would get hung up when checking that first CRL due to GSK_HTTP_CONNECT_TIMEOUT being 20 seconds.  But authentication is fast in this scenario with one HTTP CRL not being reachable.

• GSK_HTTP_CONNECT_TIMEOUT gsk-attr-name = numeric:336:<seconds>
• GSK_OCSP_TIMEOUT gsk-attr-name = number:318:<seconds>
• GSK_HTTP_CDP_TIMEOUT gsk-attr-name = numeric:319:<seconds>
• GSK_LDAP_SEARCH_TIMEOUT gsk-attr-name = number:340:<seconds>
• GSK_LDAP_CONNECT_TIMEOUT gsk-attr-name = number:343:<seconds>

Also, if WebSEAL does do the HTTP CRL checks in parallel, does it do the same for OCSP?  Or if one of the OCSP responders in a cert's AIA is unavailable, is this going to cause authentication delays waiting on timeouts to occur?

PS:  This environment is on containers, and I don't have administrator access to the container infrastructure and hence I cannot obtain a packet trace.  On the virtual appliances I would usually use packet traces to figure these types of flow questions out, although that wasn't a definite answer and more of an assumption when I saw certain behaviors.

Thanks for any thoughts!

Matt

For reference:  https://www.ibm.com/docs/en/sva/10.0.6?topic=webseal-certificate-revocation-lists