If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Extend selfserv to implement OCSP stapling

Assigned to


5 years ago
3 years ago


(Reporter: kaie, Assigned: kaie)


Dependency tree / graph

Firefox Tracking Flags

(Not tracked)



(1 attachment)



5 years ago
We should extend selfserv to support OCSP stapling for testing purposes.

I propose to start with a very simple approach, that doesn't need an external connection to an OCSP server.

If the NSS database used by selfserv contains the CA's private key, then selfserv shall be able to create its own OCSP response.


5 years ago
Blocks: 811331

Comment 1

5 years ago
In addition to selfserv code, it's also necessary to implement the server side of the cert_status handshake protocol in libSSL.

I'm attaching a first working patch that implements both.

Comment 2

5 years ago
Created attachment 694027 [details] [diff] [review]
patch v3
Assignee: nobody → kaie

Comment 3

5 years ago
Note the attached patch isn't cleaned up yet, and it might contain snippets that belong elsewhere, and of course, everything depends on the work from bug 360420. So, this patch serves mostly as a backup, at this time.

In order to test this mode of selfserv, which creates the OCSP response on its own
(without talking to an external OCSP server (yet) for simplification purposes),

I need a NSS database that contains the private keys for both the server cert and for the CA that issued the server cert. I want to create a new certificate database "stapling" as part of the test suite, which copies the "server" directory to the new directory "stapling", and imports the CA's private key from the "CA" directory.

cp server -> stapling
cd stapling
pk12util -d ../CA/ -o ca.p12 -n TestCA -K nss -W nss
pk12util -i ca.p12 -d .  -K nss -W nss
You need to log in before you can comment on or make changes to this bug.