Forum Discussion
Antoine_80417
Nimbostratus
NimbostratusMultiple certificate authorities and authentication profiles
Hello,
This is my first post on this forum so first, let me introduce myself : I'm a network an security engineer, I work for a company that uses quite a lot of F5 appliances as GTMs, LCs or LTMs with ASM module.
We are currently facing quite an issue with some of the appliances that are used as reverse proxy. We are asked to allow our clients to connect to some application using their own certificate.
The first part that we managed to figure out is the creation of the CA bundle that is advertised when the client certificate is required.
The second part on which we are struggling is the authentication profiles : we'd like to check the client certificate validity before allowing access to the application. When using a single CA, it is quite simple as you just have to create an authentication profile (OCSP or CRL) and apply it to the virtual server.
With mutliple CA, I guess I could create one authentication profile per CA and apply it to the virtual server, but I fear that may introduce some latency as there can be quite a lot of CA.
I would appreciate it a lot if you have any information on how to deal with this better than with multiple authentication profiles or on the performance that we can expect when using multiple authentication profiles.
Regards,
Antoine
Michael_YatesAre you referring to the Client Authentication portion of the SSL Profile (Client)?
Can you not create a bundle of the CA's that you want to allow to be used per SSL Profile (Client) and apply them in the "Advertised Certificate Authorities" Option? Is that not working?
You could use the provided ca-bundle which contains all well-known public certificate authorities for client-side processing.
Antoine_80417Hello Michael,
You cannont apply more than one SSL profile per Virtual Server so that's why I have to create a bundle of all the trusted CA I want to advertise. The advertisement of the CA bundle I created is working fine, we are struggling on the verification of the certificate that the client is sending. Because we have to manage different CA, we will have different CRL files so we need to find a way to match the certificate issuer to a specific CRL authentication profile.
We only want to accept certificates signed by partners CA, so we do not wish to advertise the ca-bundle that is available by default.- Michael_YatesI believe that the CRL in the Client Authentication portion of the SSL Profile (Client) is a list of revoked Client Certificates. It should not contain CA's.
If you want to filter SSL Traffic for the client and only accept SSL Certificates issued by certain CA's then you are probably going to have to write an iRule to do that.
In the CLIENTSSL_CLIENTCERT Event you can use the X509 Command:
Overall Command:
http://devcentral.f5.com/wiki/default.aspx/iRules.X509
Retrieve Issuer:
http://devcentral.f5.com/wiki/default.aspx/iRules/X509__issuer.html
Hope this helps. 
Joel_MosesHoolio, maybe you know this one since I know you've done work with extended cert revocation checking in the past: is it possible to read the issuer from a presented client cert and then use that value to change what OCSP profile you use in AUTH::start? Normally it's invoked with "[AUTH::start pam default_ssl_ocsp]", but if you know the specific name of the profile (say, my_ocsp_profile), can it be invoked with either "[AUTH::start pam tmm_my_ocsp_profile]" or "[AUTH::start pam my_ocsp_profile]"? The Wiki is a little weak in this area.
The reason I ask is that I think that's what Antoine is asking for: the ability to detect which issuer the presented client cert has, and switch between a few different revocation profiles (OCSP or CRLDP) based on that value. Might be able to be done in a modification to the authentication iRule if AUTH::start can be switched in that way.- hooleylist
Cirrostratus
I think "default_ssl_ocsp" is a PAM service--not a user configured auth profile. In the past, when I needed to support multiple client cert issuers, I created an OCSP virtual server with an iRule which changed the pool based on the issuer value in the OCSP request. I'll hunt around and see if I can find the iRule.
Aaron - Joel_Moses"default_ssl_oscp" must be some sort of internal triggername for TMM; there are, when OCSP profiles are created, matching PAM profiles that are created in /etc/pam.d on the BigIP:
admin@usherjmosesf5:Active ~ ls -la /etc/pam.d/ total 62 drwxr-xr-x 9 root root 1024 Apr 15 10:50 . drwxr-xr-x 3 root root 1024 Apr 6 10:40 .. .... drwxr-xr-x 2 root root 1024 Mar 25 16:40 ocsp -rw-r--r-- 1 root root 154 Oct 18 13:17 other -r--r----- 1 root apache 482 Apr 15 10:24 [b]pam_ocsp_ocsp_test_config[/b] -r--r----- 1 root apache 69 Apr 15 10:24 [b]pam_ocsp_ocsp_test_config.conf[/b] -rw-r--r-- 1 root root 103 Oct 18 14:06 passwd .... lrwxrwxrwx 1 root root 17 Apr 6 10:30 system-auth -> local/system-auth drwxr-xr-x 2 root root 1024 Mar 25 16:40 tacacs lrwxrwxrwx 1 root root 25 Apr 15 10:24 [b]tmm_ocsp_test_profile -> pam_ocsp_ocsp_test_config[/b] lrwxrwxrwx 1 root root 25 Apr 15 10:50 [b]tmm_my_ocsp_profile -> pam_ocsp_ocsp_test_config[/b]
So there appears to be a PAM service that is created called "tmm_my_ocsp_profile" when I create an OCSP profile called "my_ocsp_profile". I was wondering if AUTH::start would let you set to _that_ profile name rather than the standard "default_ssl_ocsp" one that the on-box OCSP iRule uses? - Antoine_80417Hi,
I do not know much about the OCSP server, but I was told that this OCSP server is capable of checking the revocation of a certificate issued by multiple CA. But this server does not have an active backup (the administrator has to make some modification for the backup server to be active), I have to find a backup solution so that client connections are not dropped in case of an outage of the OSCP server. The CRL could be that backup solution, so hoolio, if you find that iRule that you are talking about I would appreciate it a lot ! :) - hooleylistActually, are you trying to logically fail open if the OCSP server isn't available? If so, you could configure a pool containing the OCSP server address (assuming it's an IP and not a hostname) and then in your original AUTH iRule check to see if the OCSP server pool is up before trying to use AUTH::start.
However if an attacker knew this was what you were doing, they could try to take down the OCSP server and then present a revoked client cert to your VS and bypass your validation. Fail open isn't a great approach from a security perspective.
Aaron - Antoine_80417No the fail open is not a viable option. We will use CRL as a backup for OCSP.
Thanks for the iRule, i wil take a look at it and tell you if it corresponds to our needs
Antoine