Forum Discussion
MVPCRL update script issue
I have been using a script to download a CRL from the Windows CA server, convert it and import it in the BIG-IP (version 11) via the tmsh modify command, this all works fine. the only issue with this is that the BIG-IP sees this as a configuration change even if the CRL doesnt change so the cluster becomes out of sync configuration wise.
a possible solution would be to check the current CRL and the new one and only run the tmsh command if it changed, but i rather keep it as simple as possible.
is there a better way to handle this?
8 Replies
- Kevin_Stewart
Employee
I'd just add a little bit of comparison logic to your script:openssl crl -in -noout -nextupdate
If the strings match the existing CRL is still valid. - boneyard
wouldn't this mean there is a time you are running an expired CRL? even with a very small check interval there is such a moment i believe.
- Kevin_StewartThe only time the nextupdate date will change is if the CRL is different, so yes there could be a "dead spot". You could also periodically check the nextupdate value of the existing CRL, and if it exceeds a given threshold (ex. less than 2 days to expire), go out and try to get a new one, log the event, etc.
- boneyardi went for checking the CRL number to see if it was raised. it works, but it remains an annoying way to deal with this, specially as it still requires a config sync.
please F5, make a nice buildin solution for this. - Kevin_StewartIt should only require a sync if you have to update the CRL.
- boneyard
true, but that means you can get a sync at some random point when you dont want it.
- Kevin_StewartWell, to your original point, updating a flat CRL in an LTM client SSL profile will indeed be seen as a configuration change - as intended. The problem is really twofold:
1. Your flat file local CRLs expire on some semi-regular basic, requiring an update that throws the peers out of sync
2. Automatically syncing peers, without some oversight, is generally not a good thing
The root of the problem is that the object you need to update is system-dependent, which would apply to ANY object that you updated on one of the peers. The answer to this problem is really to avoid a system-dependent mechanism for certificate revocation. The Access Policy Manager module alleviates most of the pain of local CRL management with more robust certificate revocation mechanisms (OCSP and CRLDP) and is not system-dependent (aside from its static configuration). - boneyardi got your point, will look into alternatives in the future.
