SSL library needs to replace CERT_VerifyCert with new CERT_VerifyCertificate API call


16 years ago
13 years ago


(Reporter: Julien Pierre, Assigned: Nelson Bolyard (seldom reads bugmail))


Firefox Tracking Flags

(Not tracked)




16 years ago
libssl is reportedly doing multiple calls to CERT_VerifyCert for server's cert
properties - SSL cert and SSL step-up. The number of calls can be reduced with a
new API that is being worked on . See bug .


16 years ago
Depends on: 149832


16 years ago
Target Milestone: --- → 3.6

Comment 1

16 years ago
The new API is called CERT_VerifyCertificate and is working in the tip.
Summary: SSL library needs to replace CERT_VerifyCert with new API calls → SSL library needs to replace CERT_VerifyCert with new CERT_VerifyCertificate API call

Comment 2

16 years ago
It is a good idea to do this in 3.6 so that
the new function is being used, but it is
past Beta already so I'm assigning priority
Assignee: wtc → nelsonb
Priority: -- → P2

Comment 3

16 years ago
Mass retarget all my old NSS bugs that were previous targeted at NSS versions
that have now been released.  
Target Milestone: 3.6 → 3.7

Comment 4

16 years ago
With libSSL's present architecture, we could change the existing 
CERT_VerifyCert calls to CERT_VerifyCertificate, but it would be 
a lot more work to reduce those two calls into a single call, because 
the first one (the prime one) is made in a callback function that, 
in theory, is supplied by the application.  

If the application does not supply its own callback, then we use a 
default callback function in libSSL, named SSL_AuthCertificate.  
We could change SSL_AuthCertificate to use CERT_VerifyCertificate and 
check for both certUsageSSLServer and certUsageSSLServerWithStepUp,
(when called from a client).  The API to that callback expects to get 
back a SECStatus that reports whether the cert was valid for the usage
certUsageSSLServer and had the right server name in it.  The API does
not provide a way to return info about the certUsageSSLServerWithStepUp
usage.  SSL_AuthCertificate would have to use some other means (like 
reaching into SSL data structures) to return that info (or we could 
invent a new API for this purpose).  

Since NONE of the existing application-supplied callbacks check for 
certUsageSSLServerWithStepUp, we'd have to continue to separately 
check for that if the application used a callback other than 

So, the options are:
1. Change the existing CERT_VerifyCert calls into CERT_VerifyCertificate
calls, (and nothing more), or 

2. Change the existing CERT_VerifyCert calls into CERT_VerifyCertificate
calls, and add a new interface by which the callback can optionally also 
report whether the cert is ok for Step Up.  


Comment 5

16 years ago

If we are going to provide a new type of callback, I would prefer a third option :
SSL would call CERT_VerifyCertificate with *all* possible usages, before it
calls the callback.

Then, it would provide that information to the callback function, as an
argument, therefore eliminating the need for any callback function to cal
CERT_VerifyCert / CERT_VerifyCertificate again. Obviously the prototype for the
new callback would need to be slightly different to pass the extra info.

Comment 6

16 years ago
Moved to target milestone 3.8 because the original
NSS 3.7 release has been renamed 3.8.
Target Milestone: 3.7 → 3.8

Comment 7

16 years ago
Moved to NSS 3.9.
Target Milestone: 3.8 → 3.9


15 years ago
Target Milestone: 3.9 → ---

Comment 8

15 years ago
This enhancement request requires a new callback prototype.
Nominating as a NSS 4.0 feature.
Severity: normal → enhancement
Target Milestone: --- → 4.0


13 years ago
QA Contact: bishakhabanerjee → jason.m.reid


13 years ago
QA Contact: jason.m.reid → libraries
You need to log in before you can comment on or make changes to this bug.