On 15 August 2017 at 17:56, Eric Covener <covener@xxxxxxxxx> wrote:
>> When a configuration value is set to shmcb:/path/to/datafile should
>> datafile exist in the filesystem?
>
> This module always tries to use anonymous shared memory first, and
> only uses the provided path if anonymous doesn't work.
Ah, OK. Thanks.
I have a follow up question about "This Update" in the OCSP Response Data.
The config looks like this:
SSLStaplingCache shmcb:/run/httpd/ssl_stapling(32768)
The contents of /run/ doesn't persist over reboot. Unless I
misunderstand what anonymous shared memory is then that doesn't
persist over reboot. But if I connect to port 443 and look at the OCSP
Response Data I see
This Update: Aug 16 00:58:00 2017 GMT
Then I reboot the server, and connect to port 443 again and I see.
This Update: Aug 16 00:58:00 2017 GMT
When the cache doesn't persist over reboot, how is that date/time the
same after reboot?
Running httpd with "LogLevel debug" I see this appear in the log
[Wed Aug 16 13:38:23.590925 2017] [ssl:debug] [pid 1418:tid
140561596020480] ssl_util_ocsp.c(79): [client nnn.nnn.nnn.nnn:37904]
AH01973: connecting to OCSP responder 'ocsp.usertrust.com'
the first (and only first) time I connect to port 443 after reboot.
Looking at https://tools.ietf.org/html/rfc6960#page-9 I see
"OCSP responders MAY pre-produce signed responses specifying the
status of certificates at a specified time. The time at which the
status was known to be correct SHALL be reflected in the thisUpdate
field of the response."
Could it be that ocsp.usertrust.com pre-produced a response for my
certificate at "Aug 16 00:58:00 2017 GMT" and is handing that out to
my instance of httpd?
thanks,
mike
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|