i have a trap in code that pulls new ocsp dates for stapling via nginx and adds them to a sql db. yesterday, for the first time, the trap was triggered when the due date went backwards. at that time i could not duplicate the backward address as it provided the same new date after many tries.
following up today, i tried forced updating for a domain and was able to document the following:
2019-12-21 12:31:23 DIRECTORY path_to_cert OK
This OCSP update is being ‘forced’.
ECC: The OCSP validity expires at 2019-12-25 15:00:00 UTC
RSA: The OCSP validity expires at 2019-12-28 15:00:00 UTC
Reloading nginx: [ OK ]
2019-12-21 14:58:52 DIRECTORY path_to_cert OK
This OCSP update is being ‘forced’.
ECC: The OCSP validity expires at 2019-12-28 15:00:00 UTC
RSA: The OCSP validity expires at 2019-12-28 15:00:00 UTC
Reloading nginx: [ OK ]
2019-12-21 15:08:34 DIRECTORY path_to_cert OK
This OCSP update is being ‘forced’.
ECC: The OCSP validity expires at 2019-12-25 15:00:00 UTC
RSA: The OCSP validity expires at 2019-12-28 15:00:00 UTC
Reloading nginx: [ OK ]
i do not know if this serves to pin-point anything, but rsa certs do not trigger these variable time windows.
obviously, the differing time windows, supra, are both valid when served; but in the spirit of reducing bandwidth consumed by LE i set up an arbitrary window that must be entered or i back off a couple of days before re-checking. usually this means only hitting the ocsp server once or twice per week per cert.
additionally, when i originally set this proc up well over a year ago; i noticed what i thought were hokey results coming back but did not understand why. it now appears that you have multiple ocsp servers operating on non-synced data that permits wayward results to flow based on your internal server routing. it is only logical if other sysadmins have noticed the data disparities coming from your servers that they are hitting those servers far more than should be required to satisfy stapling needs.
i cannot imagine a scenario in which you would not do whatever is possible to promote and ease the use of stapling since the benefits for LE are truly manifold.
if you really wanted to slash ocsp bandwidth spikes and volumes, you could update a unified database on a schedule that would be dictated, say, by the final byte of the serial. this way you would spread incoming connections throughout the day and week and offer a mechanism whereby update requests need only be done once a week to keep stapling files current.
–
thank you,
johann