Forum Discussion

svs's avatar
svs
Icon for Cirrus rankCirrus
Jan 21, 2019

SSL client profile - certificate authentication - multiple CRL files

Hi guys,

 

currently I'm running a tests with certificate-based user authentication, using LTM/APM. In general everything is working fine, except for the fact, that there is no option to check several CRL files in one SSL client profile.

 

As there are multiple CAs, that have issued client certificates, I need to check several CRL files. The documentation is not very specific about this piece of information. There are only statements, that it is not allowed to have multiple CRLs in a single master file.

 

I have tried to use CRLDP, but this does only work in conjunction with LDAP. I can only provide the CRLs via file upload to BIG-IP or via HTTP downloads from an internal server.

 

The only idea I have so far, but which is still not tested, is to use several SSL client profiles, one for each Trusted CA, assign the correct CRL file, stored locally on the BIG-IP, and the assign the SSL client profiles dynamically, based on the requested hostname in the SNI extension.

 

To be honest, I cannot believe that there is no easier way to achieve this.

 

Any ideas on that?

 

Thanks in advance.

 

Greets,

 

svs

 

3 Replies

  • For one of my customers a bash script was created to download the crl's and with openssl concat them into one crl. (the list of crl's to download was created in a data group)

    This crl is then placed in the configuration, replacing the "old" crl file.

    tmsh modify sys file ssl-crl "allcrl.crl" source-path file:"newcrl.crl
    

    Your client ssl profile will point ti allcrl.crl containing all the revoced certificated from the CA's in the datagroup.

    Cheers,

    Kees

    • _JOHN_'s avatar
      _JOHN_
      Icon for Altocumulus rankAltocumulus

      Kees

      Sorry to post a random question in reply to one of your old comments!

      If you happen to see this, I was wondering if you could please expand further on what you meant by "download the crl's and with openssl concat them into one crl"?

      I have seen a few Dev Central posts where folks have simply concatenated PEM CRL files at the CLI, e.g. using 'cat' in bash.  However I know that openssl only 'sees' the first CRL in such a concatenated 'bundle', and when I queried F5 operation in a support request the answer was that concatenated PEM files weren't supported, e.g. couldn't use them as the CRL referenced in a client SSL profile.

      However you mentioned concatenation using openssl.  Is there a way to produce a valid single CRL file somehow from two seperate CRLs using openssl?  CRLs are signed by the relevant CA, so I'm not sure how the end file would look, but if it is possible I would really appreciate any info you can provide.

      Cheers,
      John

  • I'm gonna summarize the (working) solution, clarified with the Support.

     

    The only built-in solution for working with HTTP-based CRLs is CRLDP. CRLDP with HTTP is not working with pure LTM, but within APM (no CRLDP profile, but an CRLDP agent in VPE). Only HTTP scheme is supported, not HTTPS (that should be a very rare case, if any).

     

    If there is not CDP defined within a certificate, CRLDP will only work in conjunction with LDAP, manually configured with a proper CRLDP profile or agent.

     

    In LTM, CRLDP profile supports LDAP. In APM, CRLDP agent supports LDAP/HTTP. This information is valid for TMOS 11.4 to 14.1.

     

    If there is a need for working with multiple CRL files and

     

    • LDAP/HTTP is not available or* only HTTP is available in LTM-only mode

    you need to use alternative solutions, mostly based on bash scripts (https://devcentral.f5.com/questions/automaticlly-update-crl).

     

    There is an RFE (ID743758, "RFE: support dynamic CRL check for clientSSL profile"), requesting support for dynamic CRL files. I'm not sure about the content and this is related to CRLDP and/or multiple CRL files. Feel free to support this RFE with your cases. ;-)

     

    Greets,

     

    svs