Hi
My name is Alex.
Im developing custom application based on mozilla engine.
I have a problem, one of the features of application is to access specific
web pages, some of them have certificates, some of them have certificates
that Mozilla cant verify.
And when this happens i see dialog tittled
Eddy Nigg (StartCom Ltd.) wrote:
Just want to ask before opening a new bug: Upon visiting a newly
generated server certificate, the OCSP server wasn't ready and/or the
certificate chain wasn't complete. Ever since, I can't access this site
and receive sec_error_untrusted_cert. Even when using
Jean-Marc Desperrier wrote:
Well, CRL can also be made to scale properly to handle a large number of
revocation, but this requires a few operationnal changes.
...which presumably have to be made before you issue the certs?
The alternative in order to avoid changing the CA constantly would be
Frank Hecker wrote:
I've been looking at a request from Entrust (bug 416544) to (among other
things) have its new Entrust Root Certification Authority root enabled
for EV. This is a new Entrust root that was approved for inclusion last
year by Gerv (bug 382352) and subsequently added to NSS
Eddy Nigg (StartCom Ltd.) wrote, On 2008-06-12 04:16:
Nelson B Bolyard:
Eddy Nigg (StartCom Ltd.) wrote:
Just want to ask before opening a new bug: Upon visiting a newly
generated server certificate, the OCSP server wasn't ready and/or the
certificate chain wasn't complete. Ever since, I
2008/6/12 Eddy Nigg (StartCom Ltd.) [EMAIL PROTECTED]:
I found that Frank created http://wiki.mozilla.org/CA:Problematic_Practices
and Kathleen has started to ask questions also relating to those practices
during here information gathering and reviews.
That page lists Allowing external
Wan-Teh Chang:
That page lists Allowing external entities to operate subordinate CAs
as a problematic practice.
If a company or school needs to issue a lot of certs to its internal
servers, what is the recommended practice? I always thought the
organization should operate an intermediate CA
Nelson B Bolyard:
All trust flags are kept in the cert DB file, along with the certs to
which they are attached.
If you have the certutil utility, it would be interesting to see the output
of certutil -L for the cert(s) in question. Just be careful not to use it
at the same time as your
Eddy Nigg (StartCom Ltd.):
Hopefully I've done that correct:
certutil -L cert8.db
certutil-bin: function failed: security library: bad database.
By chance I was able to solve the problem for me, which involved
removing an exception for that domain and certificate. Now I'll poke
around if
Nelson B Bolyard:
You undoubtedly need to add a -d DIRECTORY option to that command line.
On your system, is certutil a shell script that runs a program named
certutil-bin ?
Apparently yes.
That's certainly not how the NSS team ships certutil. Sounds like another
case of somebody
Wan-Teh Chang wrote:
That page lists Allowing external entities to operate subordinate CAs
as a problematic practice.
I think that a better title for that page would be potentially
problematic practices. This is not really a binary good vs. bad
issue. There is a spectrum of possible
11 matches
Mail list logo
