OCSP responder profile with client cert set to "request", for multiple CAs;

You'd basically have an access policy that starts with an On-Demand cert auth agent that is followed by an iRule agent. That iRule would parse the client cert looking for either an AIA field or CRLDP. Depending on the logic you choose (ie. if AIA and CRLDP exist, always choose the AIA, or something like that), you'd set an access session variable. Out of the iRule event agent you'd have an empty agent and a set of branch conditions that evaluates this session variable and then routes the logic flow through an OCSP auth agent or CRLDP auth agent.

 

The APM CRLDP agent has been able to support HTTP and LDAP URLs since (I think 11.3).

 

Comments inline.

If an OCSP responder profile's URL field is empty, and "Ignore AIA" is not checked, then the URL from the AIA will be used to reach the OCSP service, correct?

Correct. It's important of course that the BIG-IP is configured with DNS and an outbound route.

Can I assume this works cleanly of "request" is set in the client SSL profile - that is, if a user doesn't provide a client certificate, this won't err out?

I believe that's correct. You must use the **_sys_auth_ssl_ocsp** iRule with LTM OCSP (or some derivation of it), and in the CLIENTSSL_CLIENTCERT event of that rule is this statement:

if {[SSL::cert count] == 0} {
    return
}

otherwise this event initiates the AUTH::authenticate function.

Finally, if a cert's AIA doesn't have an OCSP service, only an URL to a CRL ... how should that certificate be validated? If a CRLDP profile is also attached to the virtual server, will it recognize that situation and use the CRLDP profile instead? Or is there a recognized solution for handling such a mix of incoming client certificates? How about if there's no CRLDP, but only an URL to a CRL file? Can that situation be automagically handled?

Great questions. So first, I don't think an AIA would ever contain a URL to a CRL (shouldn't at least). The LTM OCSP and CRLDP functions are left over from the old ACA (advanced client authentication) module. It was great in its day, but required iRules and an internal PAM process to work, and wasn't all that flexible. Long story short, you could indeed switch between OCSP and CRLDP functions based on what the client was sending, but you'd either have to wire up a VIP-targeting solution or mesh the two iRules together. Neither of these options are trivial. This is, however, something that APM can do quite easily.