F5 LTM V11 CRL file uploading Error

when i check an imported CRL with just one entry then i only see the PEM code, not like with a certificate were you also see some more details. i can imagine that with a PEM code of 11Megabyte the system just can't handle showing it.

from what i recall the CRL just consists of serial numbers of revoked certificates, how many certificates are on the list of yours?

and perhaps a more important question does the CRL work for you? once you import it via file management i don't believe you have to place it in /config/ssl/ssl.crl/ yourself.

I believe the file size limit for flat CRLs is still 4mb. Here are a few alternatives:

1. OCSP - by far the best and fastest revocation mechanism (if you can support it), sends a single (tiny) certificate validation request (issuer and cert serial) to a remote OCSP service. Depending on you platform you may have OCSP already available to you as an LTM Authentication profile. Otherwise this is accomplished with the Access Policy Manager (APM) module.

    

2. CRLDP - this mechanism downloads and caches a remote CRL based on the CRLDP field of a certificate (user or issuer). Because it's a potentially large file, initial revocation checks can stall while the complete file is downloading. Afterwards it is cached for some length of time. CRLDP is also (possibly) available as an LTM Authentication profile, or otherwise with APM. Currently, only LDAP-based CRL retrieval is supported (not HTTP). I do not believe there is a file size limitation in the APM CRLDP cache.

    

3. Extract serial numbers to a table - a bit more complicated than the other options, use a shell script to manage and download remote CRLs, then fill a session table with serial numbers (via services VIP). The session table can handle upwards of 700k records. You don't get the warm fuzzy of a "signed" receipt, but it'll get the job done. If you have multiple CRLS, create multiple session tables, or better if the serial numbers are sequential, split them into several smaller tables that will more easily spread across the TMM instances, and then catalog where each table starts and ends.

    

Your mileage may vary with the last two options, so I highly recommend the first.

Thanks for your responses,

the CRL file size is 11M that contains more or less 269535 revoked certificates. Without placing it in the /config/ssl/ssl.crl path, when I perform the upload via GUI, I don't see at the end of the process the file uploaded in the /config/ssl/ssl.crl, I don't know if it is normal;

I have already though about OCSP which is more update and more efficient but my F5s haven't access to internet and I have no local OCSP Server available in my in frastructure.

With CRLDP, I have seen that the menu to configure an CRLDP server is available but i don't know if it really works; I'm not sure because it's reported in the APM feature too. So I guess or I don't khnow if it is reliable.

Is there anyway to ensure that CRLDP Works really on LTM and where does the cached version of the downloaded CRL file is stored in this case ? does the uploading process of the CRL from the CRL Distribution Point begin when the CRLDP Configuration is completed or is it necessary to performe an authentification so as to lauch the upload process ?

A few things:

1. If you have a Windows 2008 R2 server in your environment, then you already have a reasonable efficient OCSP responder. Otherwise there are several free and open source OCSP servers for Linux.

    

2. CRLDP requires an intial client request to initiate the CRL download. That's why the first client may stall.

    

3. The LTM CRLDP authentication profile also has the 4mb file limitation (I believe), and I'm not 100% certain where LTM keeps this file (assuming in memory or mysql).

    

4. CRLDP (LTM or APM) currently requires LDAP access to the CRLDP. No HTTP. That means that the client certificate CRLDP field either needs to be a complete ldap:// URL, or in DirName format.

    

Otherwise, CRLDP does work and is reliable.

thanks for the reply . However, i'm in a production environnent and it'll probably take much Time and projet ressource for the PKI team to validante and setup the OCsp responder even if it is techically trivial. I 'll choose your CRlDp préconisation and crossing fingers for my 11M CRL file .

Thanks a lot !! Everybody