Closed
Bug 1125375
Opened 9 years ago
Closed 9 years ago
Enhance tstclnt to offer TLS server chain diagnosis
Categories
(NSS :: Tools, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
3.18
People
(Reporter: KaiE, Assigned: KaiE)
Details
Attachments
(4 files, 1 obsolete file)
I'm very, very often asked to analyze why a connection to a certain server, with a given root CA configuration, produces an untrusted certificate result. The existing tools are cumbersome to use. Yes, we have tools to dump certificates to a file, but that requires me to manually run additional commands on separate files. In case of the vfyserv tool, it doesn't even print the chain from the server, but rather the chain that was looked up locally. I want a simple way to connect to a server, show me the full details of the certificates that have been sent. Then I want to know if NSS is able to find issuer certificates. I want to be able to tell the tool to load the default root CA module ("builtins"). Alternatively I want to specify which root module file should be loaded, without having to go through the hassle of preparing NSS database directories with modutil etc. And it would be helpful to run the tool without having to provide a NSS database at all. I've already implemented the above as a patch to tstclnt. I believe the availability of this functionality will save me and others a lot of time in the future.
Assignee | ||
Comment 1•9 years ago
|
||
The patch adds four new parameters: -D : run without a NSS database, calls NSS_NoDB_Init() -b : load the default nssckbi roots module -R file : load the given roots module from the given full path (e.g. to load the roots module from a different version of NSS, or p11-kit-trust.so etc.) -C : show a brief certificate summary -CC : show a full text dump of the certificate (same as printed by the pp utility) -CCC : same as -CC but in addition, print a PEM dump of each certificate The -C parameter will print both: - certificates sent by the server - CA certificate chain looked up locally (excluding the certificates sent by the server and that were already printed)
Assignee: nobody → kaie
Attachment #8553972 -
Flags: review?(rrelyea)
Assignee | ||
Updated•9 years ago
|
Target Milestone: --- → 3.18
Assignee | ||
Comment 2•9 years ago
|
||
The intention is to keep the default behaviour of tstclnt unchanged.
Assignee | ||
Comment 3•9 years ago
|
||
It's better to send the certificate chain information to stderr, this is where existing diagnostic output is already being sent to, it avoids interfering with input/output exchanged with the server.
Attachment #8553972 -
Attachment is obsolete: true
Attachment #8553972 -
Flags: review?(rrelyea)
Attachment #8553978 -
Flags: review?(rrelyea)
Assignee | ||
Comment 4•9 years ago
|
||
Assignee | ||
Comment 5•9 years ago
|
||
Assignee | ||
Comment 6•9 years ago
|
||
Comment 7•9 years ago
|
||
Comment on attachment 8553978 [details] [diff] [review] Patch v3 r+ it would be nice to have this functionality in vfyserv as well. bob
Attachment #8553978 -
Flags: review?(rrelyea) → review+
Assignee | ||
Comment 8•9 years ago
|
||
I've doublechecked, even when using -d dbm:dir or -d sql:dir, combined with tstclnt -b (load the builtins module), the module isn't being permanently added to the database (modutil -list doesn't list it).
Assignee | ||
Comment 9•9 years ago
|
||
https://hg.mozilla.org/projects/nss/rev/aba37bd9510c
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•