----- Original Message -----
> On 02/06/2013 07:22 PM, Nathan Scott wrote:
> >> * When using a certificate authority, it is sufficient for
> >> the
> >> clients to have the CA's signing certificate (as opposed to
> >> the
> >> server's actual certificate). This is the certificate that
> >> the
> >> CA uses to sign the certificates that it issues. If the
> >> client
> >> has the CA's signing certificate then it also trusts any
> >> certificates which are signed using that certificate. In this
> >> way, when the server's certificate expires, and it obtains a
> >> new
> >> certificate from the CA, the new certificate will be
> >> automatically trusted by clients without having to obtain a
> >> new
> >> certificate from the server.
> > Ah, that makes alot of sense. Where would the client look to find
> > the CA's certificates? I see there's an /etc/pki/nssdb that ships
> > with nspr, but it appears to be empty (no certs at all, according
> > to certutil -L). Are they installed somewhere else?
> >
> I would assume that one would get the signing certificate from the CA
> itself. I don't know for sure. The systemtap compile-server does not
> use
> certificates from a CA. It uses its own self-signed certificates.
Hmmm. So, somehow firefox manages this without manual intervention -
not sure how though? Digging around below ~/.mozilla uncovers ...
$ certutil -d /home/nathans/.mozilla/firefox/bqxm6ne3.default -L
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
VeriSign Class 3 Extended Validation SSL CA ,,
DigiCert High Assurance CA-3 ,,
VeriSign Class 3 International Server CA - G3 ,,
[snip bunch more root certs]
Looks like somehow firefox has created a NSS DB for me with all
these (root certs) plus all the ones I've added - which sounds
alot like what we're after? Just need to figure out where it's
started from with the initial DB... some code archeology is in
order I think.
cheers.
--
Nathan
|