You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@httpd.apache.org by mike _ <ar...@gmail.com> on 2017/08/15 14:26:14 UTC

[users@httpd] shmcb:/path/to/datafile datafile does not exist

I've enabled OCSP Stapling and it seems to be working, but I'm puzzled
that the file specified in SSLStaplingCache directive doesn't exist. I
see that the file specified for SSLSessionCache, which I didn't set,
doesn't exist either.

When a configuration value is set to shmcb:/path/to/datafile should
datafile exist in the filesystem?


[root@mine ~]# rpm -qa | grep -i httpd
httpd-2.4.6-45.el7.centos.4.x86_64
httpd-tools-2.4.6-45.el7.centos.4.x86_64
[root@mine ~]# head -2 /etc/os-release
NAME="CentOS Linux"
VERSION="7 (Core)"
[root@mine ~]# httpd -M | grep shmcb
 socache_shmcb_module (shared)
[root@mine ~]# grep shmcb /etc/httpd/conf.d/*
/etc/httpd/conf.d/ssl.conf:SSLSessionCache
shmcb:/run/httpd/sslcache(512000)
/etc/httpd/conf.d/ssl.conf:SSLStaplingCache shmcb:/run/httpd/ssl_stapling(32768)
[root@mine ~]# ls /run/httpd/
authdigest_shm.16570  cgisock.16570  htcacheclean  httpd.pid
[root@mine ~]#


thanks,

mike

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org


Re: [users@httpd] shmcb:/path/to/datafile datafile does not exist

Posted by mike _ <ar...@gmail.com>.
On 16 August 2017 at 13:54, Eric Covener <co...@gmail.com> wrote:
> On Wed, Aug 16, 2017 at 8:50 AM, mike _ <ar...@gmail.com> wrote:
>
>> 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?
>
> That's what I suspect. You could put a packet capture between Apache
> and the OCSP server and it would confirm that after a reboot or
> stop/start (maybe restart?) that such an OCSP response comes in on
> that backend side on the next frontend handshake (or at startup? I
> don't know much about OCSP in mod_ssl)

When I bother to look at the logs more closely I find

[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'
[Wed Aug 16 13:38:23.602557 2017] [ssl:debug] [pid 1418:tid
140561596020480] ssl_util_ocsp.c(105): [client nnn.nnn.nnn.nnn:37904]
AH01975: sending request to OCSP responder
[Wed Aug 16 13:38:23.614194 2017] [ssl:debug] [pid 1418:tid
140561596020480] ssl_util_ocsp.c(215): [client nnn.nnn.nnn.nnn:37904]
AH01981: OCSP response header: Date: Wed, 16 Aug 2017 12:38:24 GMT
[Wed Aug 16 13:38:23.614214 2017] [ssl:debug] [pid 1418:tid
140561596020480] ssl_util_ocsp.c(215): [client nnn.nnn.nnn.nnn:37904]
AH01981: OCSP response header: Server: Apache
[Wed Aug 16 13:38:23.614218 2017] [ssl:debug] [pid 1418:tid
140561596020480] ssl_util_ocsp.c(215): [client nnn.nnn.nnn.nnn:37904]
AH01981: OCSP response header: Last-Modified: Wed, 16 Aug 2017
00:58:00 GMT
[Wed Aug 16 13:38:23.614221 2017] [ssl:debug] [pid 1418:tid
140561596020480] ssl_util_ocsp.c(215): [client nnn.nnn.nnn.nnn:37904]
AH01981: OCSP response header: Expires: Wed, 23 Aug 2017 00:58:00 GMT
[Wed Aug 16 13:38:23.614223 2017] [ssl:debug] [pid 1418:tid
140561596020480] ssl_util_ocsp.c(215): [client nnn.nnn.nnn.nnn:37904]
AH01981: OCSP response header: ETag:
69D88A041D975D90EA32CB081EFFC015230776F7
[Wed Aug 16 13:38:23.614226 2017] [ssl:debug] [pid 1418:tid
140561596020480] ssl_util_ocsp.c(215): [client nnn.nnn.nnn.nnn:37904]
AH01981: OCSP response header: Cache-Control:
max-age=562175,public,no-transform,must-revalidate
[Wed Aug 16 13:38:23.614242 2017] [ssl:debug] [pid 1418:tid
140561596020480] ssl_util_ocsp.c(215): [client nnn.nnn.nnn.nnn:37904]
AH01981: OCSP response header: X-OCSP-Reponder-ID: rmdccaocsp19
[Wed Aug 16 13:38:23.614272 2017] [ssl:debug] [pid 1418:tid
140561596020480] ssl_util_ocsp.c(215): [client nnn.nnn.nnn.nnn:37904]
AH01981: OCSP response header: Content-Length: 471
[Wed Aug 16 13:38:23.614277 2017] [ssl:debug] [pid 1418:tid
140561596020480] ssl_util_ocsp.c(215): [client nnn.nnn.nnn.nnn:37904]
AH01981: OCSP response header: Connection: close

So that seems to explain the "This Update"  date/time.

(562175 seconds is about 6 and a half days.)

thanks,

mike

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org


Re: [users@httpd] shmcb:/path/to/datafile datafile does not exist

Posted by Eric Covener <co...@gmail.com>.
On Wed, Aug 16, 2017 at 8:50 AM, mike _ <ar...@gmail.com> wrote:

> 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?

That's what I suspect. You could put a packet capture between Apache
and the OCSP server and it would confirm that after a reboot or
stop/start (maybe restart?) that such an OCSP response comes in on
that backend side on the next frontend handshake (or at startup? I
don't know much about OCSP in mod_ssl)

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org


Re: [users@httpd] shmcb:/path/to/datafile datafile does not exist

Posted by mike _ <ar...@gmail.com>.
On 15 August 2017 at 17:56, Eric Covener <co...@gmail.com> 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@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org


Re: [users@httpd] shmcb:/path/to/datafile datafile does not exist

Posted by Eric Covener <co...@gmail.com>.
> 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.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org