My shy certificate
Dave Pinn
I bought a digital certificate, and installed it on my TPM chip. I have
loaded the relevant PKCS #11 module in Thunderbird; however, the
certificate on my TPM chip does not appear in Thunderbird's Certificate
Manager. I know that Thunderbird is accessing the PKCS#11 module,
because it asks me for my TPM password when I open Certificate Manager.
After reading the posts in this group, I checked that the certificate
has a nickname (Yes).
I'm wondering if it could have something to do with certificate
purposes: my certificate says that it is intended for "All application
policies", but doesn't specifically list e-mail signing as an intended
purpose.
I don't have to import the certificate into Thunderbird separately, do
I? I mean, it should stay in the TPM, and Thunderbird should be able to
see it, right?
I dunno; I'm lost. Any ideas where I should start looking for a cause?
Dave
Nelson B
> I'm newish to security issues, so be gentle with me.
>
> I bought a digital certificate, and installed it on my TPM chip. I have
> loaded the relevant PKCS #11 module in Thunderbird; however, the
> certificate on my TPM chip does not appear in Thunderbird's Certificate
> Manager.
Have you looked in all of cert manager's tabs?
> I know that Thunderbird is accessing the PKCS#11 module,
> because it asks me for my TPM password when I open Certificate Manager.
Your cert won't show up in "Your certificates" unless TBird can also find
the private key as a PKCS#11 object, with the same CKA_ID value as the
cert (and/or public key) object(s).
If you find your cert in one of the other tabs, it means that TB couldn't
find the private key that corresponds to your cert.
> After reading the posts in this group, I checked that the certificate
> has a nickname (Yes).
Modern certificates contain data elements called extensions. There are
"well known" extensions, that everybody uses, and there are other
extensions, less well known, and there may be extensions completely
unknown to TBird. Extensions may be marked "critical" (or not).
When an extension is marked critical, this tells the relying software
(such as mozilla/FF/TB) "Don't use this certificate at all, unless you fully
understand the format and meaning of this extension". So, if your cert
has an unknown critical extension, mozilla/FF/TB will ignore it.
Best bet is to get a formatted listing of the certificate itself,
showing all the extensions and their criticality.
pk11util's new -l (ell, for list) option would show you ALL the necessary
info to debug this issue, I think.
> I'm wondering if it could have something to do with certificate
> purposes: my certificate says that it is intended for "All application
> policies", but doesn't specifically list e-mail signing as an intended
> purpose.
That might cause the cert to be listed as unverified, or even invalid,
but should not cause the cert to disappear completely.
> I don't have to import the certificate into Thunderbird separately, do
> I? I mean, it should stay in the TPM, and Thunderbird should be able to
> see it, right?
Depends on the intended uses of the cert, and whether TBird has any
matching uses.
--
Nelson B
Steve Parkinson
>
> pk11util's new -l (ell, for list) option would show you ALL the necessary
> info to debug this issue, I think.
>
Woah - where have I been. This is the first time I have seen mention
of this tool.
I found the source here:
http://lxr.mozilla.org/seamonkey/source/security/nss/cmd/pk11util/
Can we get this added to the binary releases of NSS - it's not in 3.11
Steve
Nelson B
> Nelson B wrote:
>
>> pk11util's new -l (ell, for list) option would show you ALL the necessary
>> info to debug this issue, I think.
>
> Woah - where have I been. This is the first time I have seen mention
> of this tool.
Sorry, my typo. I meant PK12util. call it an "off by one" error. :)
> I found the source here:
> http://lxr.mozilla.org/seamonkey/source/security/nss/cmd/pk11util/
>
> Can we get this added to the binary releases of NSS - it's not in 3.11
Ask Relyea. He's the author of PK11util, IIRC.
--
Nelson B
Dave Pinn
> Have you looked in all of cert manager's tabs?
Yes, I have looked; it does not appear in any of Certificate Manager's tabs.
> Your cert won't show up in "Your certificates" unless TBird can also find
> the private key as a PKCS#11 object, with the same CKA_ID value as the
> cert (and/or public key) object(s).
Hmmm. I understand that HP's ProtectTools Embedded Security Manager
encrypts private keys. Here's an excerpt from a document entitled "HP
ProtectTools Embedded Security – the HP Trusted Computing implementation":
"In a conventional security implementation, the private key is stored on
the local hard drive, potentially compromising the user’s digital
identity. One of the primary applications for ProtectTools Embedded
Security is to help provide stronger protection for the user’s digital
identity by encrypting the private key with another key that is uniquely
associated with the given user and resides within the TPM itself."
I'm wondering if that means that the private key is unavailable to
Thunderbird; although, if ProtectTools implements the PKCS#11 standard...
> Modern certificates contain data elements called extensions. There are
> "well known" extensions, that everybody uses, and there are other
> extensions, less well known, and there may be extensions completely
> unknown to TBird. Extensions may be marked "critical" (or not).
> When an extension is marked critical, this tells the relying software
> (such as mozilla/FF/TB) "Don't use this certificate at all, unless you fully
> understand the format and meaning of this extension". So, if your cert
> has an unknown critical extension, mozilla/FF/TB will ignore it.
>
> Best bet is to get a formatted listing of the certificate itself,
> showing all the extensions and their criticality.
>
> pk11util's new -l (ell, for list) option would show you ALL the necessary
> info to debug this issue, I think.
Right-oh. I'd love to run pk11util. Do you know of a binary build of
pk11util for Windows XP?
Dave Pinn
> Right-oh. I'd love to run pk11util. Do you know of a binary build of
> pk11util for Windows XP?
Hang on, am I being blonde? is NSS something that I can download and
run, which incorporates pk11util?
Peter Djalaliev
In your first posting, you said that you have loaded "the relevant
PKCS#11 module". What module are you using? Is it provided with
ProtectTools?
Otherwise, I read through some of the HP ProtectTools Embedded Security
Manager whitepapers and it seems that the private key and certificate
should both be accessible through the PKCS#11 interfaces.
The master storage key, which is generated by the TPM, never leaves the
TPM. However, the private key, which goes with the digital certificate
you bought, is protected by the master storage key (or by a chain of
keys which is in turn protected by the master storage key) and should
be available to NSS.
Please tell us when you find the solution, I am quite interested :)
Regards,
Peter
Dave Pinn
> Hello Dave,
>
> In your first posting, you said that you have loaded "the relevant
> PKCS#11 module". What module are you using? Is it provided with
> ProtectTools?
The module ships with ProtectTools as a DLL: ifxtpmck.dll, to be precise.
> Otherwise, I read through some of the HP ProtectTools Embedded Security
> Manager whitepapers and it seems that the private key and certificate
> should both be accessible through the PKCS#11 interfaces...
Cool!
> Please tell us when you find the solution, I am quite interested :)
I certainly will. I'm new to cryptography and digital security in
general, and I'm having much more fun than is reasonable sorting it all
out. When I bought my notebook (Compaq nw8440, if you are interested), I
had no idea that it came with an embedded security chip, nor any of the
marvelous software that manages it. I bought the digital certificate
just for fun - I must be mad.
I have a sneaking suspicion now that it is the certificate that is
wonky. It is provided by verisign, but is is special: it is compliant
with Gatekeeper (http://www.verisign.com.au/gatekeeper/), which is an
initiative of the Australian Federal Government.
If only I put print out the details of the certificate and post them
here so that everyone could check them out for me. Gotta be careful,
though, that I don't publish something that should be secret.
Dave Pinn
> Best bet is to get a formatted listing of the certificate itself,
> showing all the extensions and their criticality.
OK, here goes:
Non-critical X.509 version 3 extensions:
* CRL Distribution Points
* Authority Key Identifier
* Subject Key Identifier
* Authority Information Access
* Subject Alternative Name
* Netscape Cert Type
* Certificate Policies
Critical X.509 version 3 extensions (values shown below keys):
* Basic Constraints
- Subject Type=End Entity, Path Length Constraint=None
* Key Usage
- Digital Signature, Non-Repudiation (c0)
I don't have a clue what it all means. Is it all good?
Nelson B Bolyard
NSS is a set of shared libraries, and test tool programs for those libraries.
pk11util and pk12util are among the many test tool programs for NSS.
The libraries are used by many products, including the mozilla family of
browsers and email clients, Sun Java Enterprise Servers, Solaris 10,
various Linux distributions, and lots of other products (most of which are
unknown to the NSS developers). The binaries for the libraries are part of
any of those product downloads. However, the test tools are typically not.
NSS is open source. It's possible to download the sources and build a
full release of NSS from them. (I do this about daily). The sources are
available from mozilla's ftp and cvs servers.
Periodically, there are numbered releases of NSS. For MOST but not all
such releases, a set of precompiled binaries of NSS libraries and test
tools are made available for download from ftp.mozilla.org. Look in
ftp://ftp.mozilla.org/pub/mozilla.org/security/nss/releases
The most recent release for which binaries are available is NSS 3.11 .
The most recent source release is NSS 3.11.2 .
If you're willing to download and play with NSS 3.11 (or later) I can make
a binary build of NSS 3.11.2 for WinXP available to you, and provide you
some initial instructions/tips for it.
--
Nelson B
Nelson B Bolyard
Yes. Looks perfect. No unknown critical extensions there.
All these extensions are known to mozilla products, except for the
Policies extension which is not critical.
In short, I see no reason among those extensions why the cert should not
appear in the cert list of FF or TB.
Out of curiosity, what tool(s) did you use to get that data?
--
Nelson B
Nelson B Bolyard
You run the "DOS prompt" (or other command line window) and run the programs
in that window.
I'd suggest a sequence of steps something like this:
1) use modutil to get a listing of all the PKCS#11 modules that have been
configured into Thunderbird. If your new laptop's PKCS#11 module is not
among them, that's the first thing to fix.
2) use certutil to get a listing of the certificates available to TBird
from that PKCS#11 module, and to find out if the private key corresponding
to that cert is accessible to TBird. Certutil will also show us what the
certificate would look like to TBird (if TBird would show it).
3) Beyond that, other utilities as needed, depending on what those utilties
show us.
--
Nelson B
Dave Pinn
> Out of curiosity, what tool(s) did you use to get that data?
An Embedded Security Certificate Viewer is part of HP's ProtectTools
suite. There's no way to copy the output of the viewer to the clipboard,
so I had to transpose it manually.
Dave Pinn
...
> 1) use modutil to get a listing of all the PKCS#11 modules that have been
> configured into Thunderbird. If your new laptop's PKCS#11 module is not
> among them, that's the first thing to fix.
I downloaded the NSS 3.11 binary build for WINNT5.0 - there were no
builds for Win XP specifically - and the corresponding NSPR 4.6 binary
build. When I run modutil -list, I get the following error message:
ERROR: Directory "/.netscape" does not exist.
Dave Pinn
files from my Thunderbird profile directory:
1. cert8.db
2. key3.db
3. secmod.db
I then ran modutil -list, which produced the following output:
Listing of PKCS #11 Modules
-----------------------------------------------------------
1. NSS Internal PKCS #11 Module
slots: 2 slots attached
status: loaded
slot: NSS Internal Cryptographic Services
token: NSS Generic Crypto Services
slot: NSS User Private Key and Certificate Services
token: NSS Certificate DB
2. Builtin Roots Module
library name: C:\Program Files\Mozilla Thunderbird\nssckbi.dll
slots: 1 slot attached
status: loaded
slot:
token: Builtin Object Token
3. HP TPM
library name: C:\WINDOWS\system32\IfxTpmCk.dll
slots: 1 slot attached
status: loaded
slot: HP ProtectTools Embedded Security Chip
token: Embedded Security Chip
-----------------------------------------------------------
So it appears that the ProtectTools PKCS#11 module is loaded. Now for
certutil; stay tuned.
Dave Pinn
deleted to protect my privacy):
Gatekeeper TYPE 3 CA - eSign Australia CT,C,C
Gatekeeper Grade 3 Individual CA - eSign Australia CT,C,C
Gatekeeper Root CA - eSign Australia CT,C,C
What conclusions should I now draw?
Nelson Bolyard
modutil uses a command line option to tell it the name of the
directory to look in. The option is
-dbdir directoryname
e.g.
-dbdir "c:/documents and settings/me/Application Data/Mozilla/profiles/..."
The default, when no such option is specified, is to look in $HOME/.netscape
where $HOME is the value of the environment variable named HOME.
What you did, creating /.netscape and copying file to there, also works just
fine, and is probably simpler and safer.
from the about output: draw no conclusions about your TPM chip.
You got a listing of the certs in mozilla's own certdb, not the certs in
your TPM. By default, certutil looks only in the "NSS Certificate DB" slot.
To get it to look in another slot, you must tell in which slot to examine.
Try
certutil -L -h all
to get a list of all certs in all slots.
If that still doesn't show them try with the slot name
certutil -L -h "HP ProtectTools Embedded Security Chip"
or try wiht the token name
certutil -L -h "Embedded Security Chip"
Certs from your TPM should show their "nicknames" (a.k.a. "friendly names")
preceeded by the slot name or token name, e.g.
HP ProtectTools Embedded Security Chip: Some Certificate Name
or
Embedded Security Chip: Some Certificate Name
You might expect to see a line that looks something like this:
Embedded Security Chip:TPM Certificate u,u,
Those comma-separated letters at the end of the line tell you things
about the certificate. If the PKCS#11 module has made the private key
available to NSS, the letter "u" will show up in that string 1-3 times.
If it doesn't, then the PKCS#11 module is not presenting the private key
to mozilla in a way that enables mozilla to associated the private key
with the certificate (or perhaps not at all).
If your certutil output lists any such certs, then try a command like:
certutil -L -n "Embedded Security Chip:Some Certificate name"
(using whatever name you get from the certutil -L command, and not
the example name I showed above. Be sure to use the quotation marks.)
That should show you the entire certificate, as mozilla will see it.
/Nelson
Dave Pinn
> Try
> certutil -L -h all
> to get a list of all certs in all slots.
X:\ThunderbirdProfile>certutil -L -h all -d .
Enter Password or Pin for "Embedded Security Chip":
Gatekeeper Root CA - eSign Australia CT,C,C
Gatekeeper Grade 3 Individual CA - eSign Australia CT,C,C
Gatekeeper TYPE 3 CA - eSign Australia CT,C,C
Builtin Object Token:Verisign/RSA Secure Server CA CG,C,p
Builtin Object Token:GTE CyberTrust Root CA CG,C,C
Builtin Object Token:GTE CyberTrust Global Root CG,C,C
Builtin Object Token:Thawte Personal Basic CA p,C,C
Builtin Object Token:Thawte Personal Premium CA p,C,C
Builtin Object Token:Thawte Personal Freemail CA p,C,p
Builtin Object Token:Thawte Server CA CG,p,C
Builtin Object Token:Thawte Premium Server CA CG,p,C
Builtin Object Token:Equifax Secure CA C,C,C
Builtin Object Token:ABAecom (sub., Am. Bankers Assn.) Root CA CG,C,C
Builtin Object Token:Digital Signature Trust Co. Global CA 1 CG,C,C
Builtin Object Token:Digital Signature Trust Co. Global CA 3 CG,C,C
Builtin Object Token:Digital Signature Trust Co. Global CA 2 CG,C,C
Builtin Object Token:Digital Signature Trust Co. Global CA 4 CG,C,C
Builtin Object Token:Verisign Class 1 Public Primary Certification
Authority p,C,p
Builtin Object Token:Verisign Class 2 Public Primary Certification
Authority p,C,C
Builtin Object Token:Verisign Class 3 Public Primary Certification
Authority CG,C,C
Builtin Object Token:Verisign Class 1 Public Primary Certification
Authority - G2 p,C,p
Builtin Object Token:Verisign Class 2 Public Primary Certification
Authority - G2 p,C,C
Builtin Object Token:Verisign Class 3 Public Primary Certification
Authority - G2 C,C,C
Builtin Object Token:Verisign Class 4 Public Primary Certification
Authority - G2 CG,C,C
Builtin Object Token:GlobalSign Root CA C,C,C
Builtin Object Token:ValiCert Class 1 VA C,C,C
Builtin Object Token:ValiCert Class 2 VA C,C,C
Builtin Object Token:RSA Root Certificate 1 C,C,C
Builtin Object Token:Verisign Class 1 Public Primary Certification
Authority - G3 p,C,p
Builtin Object Token:Verisign Class 2 Public Primary Certification
Authority - G3 p,C,C
Builtin Object Token:Verisign Class 3 Public Primary Certification
Authority - G3 C,C,C
Builtin Object Token:Verisign Class 4 Public Primary Certification
Authority - G3 CG,C,C
Builtin Object Token:Entrust.net Secure Server CA C,C,C
Builtin Object Token:Entrust.net Secure Personal CA C,C,C
Builtin Object Token:Entrust.net Premium 2048 Secure Server CA C,C,C
Builtin Object Token:Baltimore CyberTrust Root C,C,p
Builtin Object Token:Equifax Secure Global eBusiness CA C,C,C
Builtin Object Token:Equifax Secure eBusiness CA 1 C,C,C
Builtin Object Token:Equifax Secure eBusiness CA 2 C,C,C
Builtin Object Token:Visa International Global Root 2 C,C,p
Builtin Object Token:beTRUSTed Root CA C,C,C
Builtin Object Token:AddTrust Low-Value Services Root C,C,p
Builtin Object Token:AddTrust External Root C,C,C
Builtin Object Token:AddTrust Public Services Root ,,
Builtin Object Token:AddTrust Qualified Certificates Root C,C,C
Builtin Object Token:Verisign Class 1 Public Primary OCSP Responder C,C,C
Builtin Object Token:Verisign Class 2 Public Primary OCSP Responder C,C,C
Builtin Object Token:Verisign Class 3 Public Primary OCSP Responder C,C,C
Builtin Object Token:Verisign Secure Server OCSP Responder C,C,C
Builtin Object Token:Verisign Time Stamping Authority CA C,C,C
Builtin Object Token:Thawte Time Stamping CA C,C,C
Builtin Object Token:Entrust.net Global Secure Server CA C,C,C
Builtin Object Token:Entrust.net Global Secure Personal CA C,C,C
Builtin Object Token:AOL Time Warner Root Certification Authority 1 C,C,C
Builtin Object Token:AOL Time Warner Root Certification Authority 2 C,C,C
Builtin Object Token:beTRUSTed Root CA-Baltimore Implementation C,C,C
Builtin Object Token:beTRUSTed Root CA - Entrust Implementation C,C,C
Builtin Object Token:beTRUSTed Root CA - RSA Implementation C,C,C
Builtin Object Token:RSA Security 2048 v3 C,C,C
Builtin Object Token:RSA Security 1024 v3 C,C,C
Builtin Object Token:GeoTrust Global CA C,C,C
Builtin Object Token:UTN-USER First-Network Applications C,C,C
Builtin Object Token:America Online Root Certification Authority 1 C,C,C
Builtin Object Token:America Online Root Certification Authority 2 C,C,C
Builtin Object Token:Visa eCommerce Root C,C,C
Builtin Object Token:TC TrustCenter, Germany, Class 2 CA C,C,C
Builtin Object Token:TC TrustCenter, Germany, Class 3 CA C,C,C
Builtin Object Token:Certum Root CA C,C,C
Builtin Object Token:Comodo AAA Services root C,C,C
Builtin Object Token:Comodo Secure Services root C,C,C
Builtin Object Token:Comodo Trusted Services root C,C,C
Builtin Object Token:IPS Chained CAs root C,C,C
Builtin Object Token:IPS CLASE1 root C,C,C
Builtin Object Token:IPS CLASE3 root C,C,C
Builtin Object Token:IPS CLASEA1 root C,C,C
Builtin Object Token:IPS CLASEA3 root C,C,C
Builtin Object Token:IPS Servidores root C,C,C
Builtin Object Token:IPS Timestamping root C,C,C
Builtin Object Token:QuoVadis Root CA C,C,C
Builtin Object Token:Security Communication Root CA C,C,C
Builtin Object Token:Sonera Class 1 Root CA p,C,p
Builtin Object Token:Sonera Class 2 Root CA C,C,C
Builtin Object Token:Staat der Nederlanden Root CA C,C,C
Builtin Object Token:TDC Internet Root CA C,C,C
Builtin Object Token:TDC OCES Root CA C,C,C
Builtin Object Token:UTN DATACorp SGC Root CA C,p,p
Builtin Object Token:UTN USERFirst Email Root CA p,C,p
Builtin Object Token:UTN USERFirst Hardware Root CA C,p,p
Builtin Object Token:UTN USERFirst Object Root CA p,p,C
Builtin Object Token:Camerfirma Chambers of Commerce Root C,C,C
Builtin Object Token:Camerfirma Global Chambersign Root C,C,C
Builtin Object Token:NetLock Notary (Class A) Root C,C,C
Builtin Object Token:NetLock Business (Class B) Root C,C,C
Builtin Object Token:NetLock Express (Class C) Root C,C,C
Builtin Object Token:XRamp Global CA Root C,C,C
Builtin Object Token:Go Daddy Class 2 CA C,C,C
Builtin Object Token:Starfield Class 2 CA C,C,C
X:\ThunderbirdProfile>
> If that still doesn't show them try with the slot name
> certutil -L -h "HP ProtectTools Embedded Security Chip"
Tried that: got exactly the same output as above.
> or try wiht the token name
> certutil -L -h "Embedded Security Chip"
X:\ThunderbirdProfile>certutil -L -h "Embedded Security Chip" -d .
Enter Password or Pin for "Embedded Security Chip":
X:\ThunderbirdProfile>
That cannot be good, and Yes, I'm sure that I got the password right.
> Certs from your TPM should show their "nicknames" (a.k.a. "friendly names")
Not so much.
I used modutil to give me some more information about the TPM:
X:\ThunderbirdProfile>modutil -dbdir . -list "HP TPM"
Using database directory ....
-----------------------------------------------------------
Name: HP TPM
Library file: C:\WINDOWS\system32\IfxTpmCk.dll
Manufacturer: Infineon Technologies AG
Description: TPM Cryptoki Provider
PKCS #11 Version 2.11
Library Version: 2.0
Cipher Enable Flags: None
Default Mechanism Flags: None
Slot: HP ProtectTools Embedded Security Chip
Slot Mechanism Flags: None
Manufacturer: Infineon Technologies AG
Type: Hardware
Version Number: 1.0
Firmware Version: 1.0
Status: Enabled
Token Name: Embedded Security Chip
Token Manufacturer: Infineon Technologies AG
Token Model: SLD 9630 TT 1.1
Token Serial Number: N/A
Token Version: 1.0
Token Firmware Version: 1.0
Access: NOT Write Protected
Login Type: Login required
User Pin: Initialized
-----------------------------------------------------------
X:\ThunderbirdProfile>
Nelson B
>> or try wiht the token name
>> certutil -L -h "Embedded Security Chip"
>
> X:\ThunderbirdProfile>certutil -L -h "Embedded Security Chip" -d .
> Enter Password or Pin for "Embedded Security Chip":
>
> X:\ThunderbirdProfile>
>
> That cannot be good, and Yes, I'm sure that I got the password right.
OK. The fact that it prompted you for a password indicates that you did
talk to the PKCS#11 module. It suggests that
a) the PKCS#11 module is not making the certificate available, or
b) the certificate cannot be parsed by NSS for some reason, or
c) some other problem with the PKCS#11 module.
There are more tools, including one that will go right down into the
PKSC#11 module and examine the actual bits of its responses. But this
is a debugging tool, designed to help the writers of PKCS#11 modules
debug their modules. Even if you found something this way, you couldn't
fix it (unless you're a developer of that PKCS#11 module or have source
code for it).
I think this is the point at which it is reasonable for you to ask your
laptop maker to support their product. Ask 'em if they tested with any
mozilla browser or email products.
If you can get the complete binary certificate out of the thing, and
can send me the certificate, I can examine that. That's about all that
we haven't done that's reasonable to do, at this point, IMO.
I wonder if they put the certificate into (say) windows certificate store
rather than into the TPM. Perhaps all they put into the TPM is the private
key?
--
Nelson B
Dave Pinn
certificate *into* my PKCS#11 module?
Umesh Bywar
Have a look at security/manager/ssl/src/nsPKCS12Blob.cpp.
nsresult nsPKCS12Blob::ImportSSLCertsFromFile(nsILocalFile *file) {
nsNSSShutDownPreventionLock locker;
nsresult rv;
SECStatus srv = SECSuccess;
SEC_PKCS12DecoderContext *dcx = NULL;
SECItem unicodePw;
PK11SlotInfo *slot=nsnull;
nsXPIDLString tokenName;
NS_NAMED_LITERAL_STRING(password, "passwd");
if (!mToken) {
if (!mTokenSet) {
rv = SetToken(NULL); // Ask the user to pick a slot
if (NS_FAILED(rv)) {
handleError(PIP_PKCS12_USER_CANCELED);
return rv;
}
}
}
if (!mToken) {
handleError(PIP_PKCS12_RESTORE_FAILED);
return NS_ERROR_NOT_AVAILABLE;
}
PRBool needsInit;
mToken->GetNeedsUserInit(&needsInit);
if(needsInit)
mToken->InitPassword(EmptyString().get());
unicodeToItem(password.get(), &unicodePw);
mToken->GetTokenName(getter_Copies(tokenName));
NS_ConvertUTF16toUTF8 tokenNameCString(tokenName);
slot = PK11_FindSlotByName(tokenNameCString.BeginWriting());
if (!slot) {
srv = SECFailure;
goto finish;
}
// initialize the decoder
dcx = SEC_PKCS12DecoderStart(&unicodePw, slot, NULL,
digest_open, digest_close,
digest_read, digest_write,
this);
if (!dcx) {
srv = SECFailure;
goto finish;
}
// read input file and feed it to the decoder
rv = inputToDecoder(dcx, file);
if (NS_FAILED(rv)) {
if (NS_ERROR_ABORT == rv) {
// inputToDecoder indicated an NSS error
srv = SECFailure;
}
goto finish;
}
// verify the blob
srv = SEC_PKCS12DecoderVerify(dcx);
if (srv) goto finish;
// validate bags
srv = SEC_PKCS12DecoderValidateBags(dcx, nickname_collision);
if (srv) goto finish;
// import cert and key
srv = SEC_PKCS12DecoderImportBags(dcx);
if (srv) goto finish;
finish:
if (srv != SECSuccess) {
handleError(PIP_PKCS12_NSS_ERROR);
} else if (NS_FAILED(rv)) {
handleError(PIP_PKCS12_RESTORE_FAILED);
}
if (slot)
PK11_FreeSlot(slot);
// finish the decoder
if (dcx)
SEC_PKCS12DecoderFinish(dcx);
return NS_OK;
}
--
Best Regards.
Umesh.
"Dave Pinn" <dp...@byandlarge.net> wrote in message news:U_idnTuSq8Gv60TZ...@mozilla.org...
> Is there a Mozilla utility with which I can attempt to import a
> certificate *into* my PKCS#11 module?
> _______________________________________________
> dev-tech-crypto mailing list
> dev-tec...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
Dave Pinn
why it worked remains a mystery.
I deleted my certificate from ProtectTools; I then imported it into
Thunderbird, selecting "Embedded Security Chip" as the token. Simple,
huh? Why didn't I try that earlier, I ask myself.
One thing still puzzles me. There's an icon in ProtectTools Certificate
Viewer for each certificate; the one next to the certificate that I
added to Thunderbird "is used for certificates without corresponding
private key" (according to the Help documentation). So where is the
private key? Could it still be in Thunderbird's certificate database? I
don't want it in there; I want it to be safely stored away in the TPM.
Can good 'ol modutil and certutil help me determine where my private key is?
Arshad Noor
since certutil cannot see your certificate, you should
attempt to see if the certificate is in the Windows
certificate-store (it is more likely that the cert is
there than in the Mozilla cert-store).
Two ways of verifying this:
1) a) Select Start->Run and type in certmgr.msc
b) When the Certificate window pops-up, expand
Personal and select Certificates. If you see
your certificate on the right-hand side, then
you've found it.
c) Select the certificate itself, and either select
Action-> All Tasks->Export from the menu, or just
right-click on the cert and select All Tasks->
Export
d) Use the wizard to export the certifcate to a
Base64-encoded certificate in a filename of your
choice
e) Use certutil from the Command Prompt window (or
the Firefox browser)to import it into NSS.
2) If you do not have certmgr.msc on your machine,
a) Startup the Internet Explorer browser
b) Select Tools->Internet Options from the IE men
c) Select Content->Certificates from the panel that
pops-up
d) If you see your certificate under the Personal
tab, you've found it
e) Select the certificate and click on Export...
f) Use the wizard to export the certifcate to a
Base64-encoded certificate in a filename of your
choice
g) Use certutil from the Command Prompt window (or
the Firefox browser)to import it into NSS.
Once you have the Base64-encoded certificate in a file,
you can paste it into an e-mail in this forum if you
need additional help on the certificate.
Arshad Noor
StrongAuth, Inc.
Arshad Noor
the Private Key from the TCP chip.
But if you did delete it from ProtectTools, where did you find a
certificate to import it into Thunderbird?
Thunderbird allows you to import a cert into its cert-store even
without a Private Key, because the tool can legitimately use a
certificate to encrypt e-mails with it. However, the certificate
most likely will not show up as Your Certificate, but as belonging
to Other People.
The Private Key was in the TCP chip (ProtectTools), but if you
deleted the certificate associated with it, you've likely deleted
the Private Key too.
BTW, what model of the HP comes with this chip? Thanks.
Arshad Noor
StrongAuth, Inc.
Dave Pinn
> You may have been a little hasty, Dave.
It wouldn't be the first time, Arshad.
> I suspect you've deleted the Private Key from the TCP chip.
Hmm. I think you may be right.
> But if you did delete it from ProtectTools, where did you find a
> certificate to import it into Thunderbird?
I obtained the certificate from Verisign, using IE, from which I
exported a .p12 file. I cunningly saved the .p12 file for just an emergency.
> Thunderbird allows you to import a cert into its cert-store even
> without a Private Key, because the tool can legitimately use a
> certificate to encrypt e-mails with it. However, the certificate
> most likely will not show up as Your Certificate, but as belonging
> to Other People.
No, it shows up under "Your Certificates" - this is a good thing, Yes? I
send a signed e-mail to myself, and, as the recipient, successfully
validated the signature. So that private key is lurking around
somewhere, right? It may not be in the TPM, but it lives.
> The Private Key was in the TCP chip (ProtectTools), but if you
> deleted the certificate associated with it, you've likely deleted
> the Private Key too.
>
> BTW, what model of the HP comes with this chip? Thanks.
The model is Compaq nw8440. It has a TPM chip, fingerprint reader, and
adds all manner of enhanced security features, like: creation of virtual
encrypted drive, hard disk drive locking, BIOS protection, and enhanded
folder encryption. Way cool.
Thanks for taking an interest, Arshad.
Arshad Noor
your favor. You do have the Private Key; it is inside the
P12 file you created (I made the incorrect assumption that
the key was generated in the TCP chip and could not be
exported).
If you enrolled for the certificate using IE, then your
certificate was definitely in the Windows cert-store, and
the two methods I wrote a little while ago would have shown
them to you.
Now that you have the P12 file, you can import it back again
into ProtoectTools. You can also export just the certificate
from your IE/Windows cert-store and import it into Thunderbird.
Once Thunderbird has your certificate, *and* it sees the TCP
module, it will see the certificate as one for which you have
the Private Key, thus allowing you to sign and/or receive
encrypted e-mails. Good luck.
Arshad Noor
StrongAuth, Inc.
Bob Relyea
> Is there a Mozilla utility with which I can attempt to import a
> certificate *into* my PKCS#11 module?
> dev-tech-crypto mailing list
> dev-tec...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
pk12util.
pk12util -i mycert.p12 -d /.netscape -h "Embedded Security Chip"
where mycert.p12 is your p12 file and /.netscape is the nss database you
created with modutil.
NSS is clearly seeing your pkcs11 module, It's just not finding any
certs in it.
You can also use Firefox:
Tools->Options->Security->Security Devices->Load (to load your PKCS #11
file if you haven't already).
Tools->Options->Security->View Certificates->Import (to load your
certificate).
Note: These will only work if your pkcs #11 module is write able and
supports C_CreateObject(). They both use the same underlying code, so
you only need to try one (if it fails, the other method would most
likely fail as well).
bob
Wan-Teh Chang
with a TPM to play with. I'm glad that HP provides
a PKCS #11 library for the TPM.
Dave, do you need to enter a PIN or password to use
the private key stored in the TPM?
Wan-Teh
Nelson B
One thing that isn't clear to me: how (with what program, by what exact steps)
did you originally generate your pair of keys and get your certificate?
I'm thinking now that perhaps you did it with some tool that did not use
your TPM, and consequently, the private key was never in the TPM.
Perhaps you did it with your mozilla-family product, or perhaps with Windows
own certificate manager or cert enrollment software, and that software used
its own native key generation and key storage, rather than the TPM.
In that case, the private key you have now is not in your TPM, and getting
it into the TPM may yet be a problem. Some TPM devices will only work with
private keys that they generate themselves. That is, they will not let you
import a private key into them.
Now you have a cert and private key, working in mozilla (FF/TB/SM), but
I think we have not yet established that the private key is in the TPM.
You may find it difficult to import the private key into the TPM.
So, assuming that you're the first of many future HP TPM users, please help
us to understand exactly how you got that private key in the first place.
--
Nelson B
Anders Rundgren
>This thread makes me want to buy a laptop or PC
>with a TPM to play with.
You will be even more interested buying into this when
the TPM is in your mobile phone and connects to the
PC (and NSS) through NFC/WLAN. The silicon
cost for the TPM is about 50cent according to vendors.
>I'm glad that HP provides
>a PKCS #11 library for the TPM.
Dell provides this as well. Probably there are
some 100 000 TPM-equipped boxes out there.
Some web-servers also support TPMs which could
be of interest for securing SSL certs although I don't
think the TPM are quite as fast as a good x86 chip.
>Dave, do you need to enter a PIN or password to use
>the private key stored in the TPM?
He should, I need to do that on my dell M70.
Anders
David Pinn
> Dave, do you need to enter a PIN or password to use
> the private key stored in the TPM?
Yes, Thunderbird asks me for my password to the Embedded Security Chip,
presumably as part of its interaction with the TPM via PKCS#11.
Dave Pinn
> So, assuming that you're the first of many future HP TPM users, please help
> us to understand exactly how you got that private key in the first place.
With pleasure:
On a desktop PC, I opened Mozilla Firefox, and navigated to
http://www.verisign.com.au/gatekeeper/individual.shtml. I clicked Buy
Now, and followed the instructions presented to me. At a point in that
process, I was informed that public and private keys had been created
for me. Further, I was informed that, when I eventually received my
certificate - it takes about a week - I would have to download and
install it using the same machine with which I had registered.
I then took an inordinate number of identity evidence documents to the
post office, had an interview, and submitted a form.
A week later, I received an e-mail with instructions on how to download
my certificate. Again using my desktop PC, I downloaded the certificate
- well two actually: one for signing, and one for encrypting - and
installed it in Firefox. I don't remember the exact sequence of key
presses, but I know that it had to be done from the same browser that I
had used for registration.
I also downloaded the root certificate for GateKeeper.
I opened Firefox's Certificate Manager, highlighted one of the
certificates, clicked Backup, entered a new file name, and clicked Save.
Firefox required me to enter a password that would protect the new file.
Firefox then informed me, "Successfully backed up your security
certificate(s) and private key(s)."
I did the same with the other certificate.
I copied the two files to my notebook: the one with the TPM. I opened
the Embedded Security Certificate Viewer, and clicked Import. I selected
one of the backup .p12 files, and entered the password that I had used
to protect it. The certificate was successfully imported, and showed up
in the Certificate Viewer. I did the same with the other certificate
file. The icons next to the imported certificates indicated that the
private keys had been successfully imported.
Nelson Bolyard
Thank you for the detailed explanation. It all makes sense now.
You generated the key pair on a PC that didn't have the TPM chip.
So the private key couldn't have been generated in the TPM chip,
and when you generated it, mozilla (FF/TB/SM) didn't ask you which
device you wanted to use to generate the keypair because, on that
machine, there was no choice to be made.
Now, you've imported the .p12 file onto the laptop, and we *think*
that it's finally on the TPM, but I'd like to confirm that.
Please redo the certutil list test,, e.g.
certutil -L -h "Embedded Security Chip" -d X:/ThunderbirdProfile
and see if you get a non-empty output this time, and if it shows that
you have the private key in the TPM this time.
(Be sure that Thunderbird is not running when you do that!)
Thanks again, and best regards,
/Nelson
Dave Pinn
notebook (the one with the TPM):
1. Certificates directly (via ProtectTools import function) and fully
(the icons indicate that private keys are available) imported into the
TPM. This is the state in which I found my machine at the end of the
certificate purchase process that I described earlier in detail. In this
state, Thunderbird *cannot* see the certificates; nor can certutil.
2. Certificates indirectly (via Thunderbird) imported into the TPM. In
this state, Thunderbird can see and use the certificates to sign and
validate signed e-mails; but the icons in the ProtectTools Certificate
Viewer show that the private key is not available. certutil *can* see
the certificates (I will re-verify this later tonight). It is unclear to
me where the private keys are in fact stored; and that is my only
remaining concern.
Dave
Nelson B
> I need to clarify something: there are two states in which I can have my
> notebook (the one with the TPM):
>
> 1. Certificates directly (via ProtectTools import function) and fully
> (the icons indicate that private keys are available) imported into the
> TPM. This is the state in which I found my machine at the end of the
> certificate purchase process that I described earlier in detail. In this
> state, Thunderbird *cannot* see the certificates; nor can certutil.
That's an issue that the developers of the PKCS#11 module for the TPM
need to investigate. If they want help from mozilla developers, we're
willing to help them. I encourage you to raise that issue with them.
> 2. Certificates indirectly (via Thunderbird) imported into the TPM. In
> this state, Thunderbird can see and use the certificates to sign and
> validate signed e-mails; but the icons in the ProtectTools Certificate
> Viewer show that the private key is not available. certutil *can* see
> the certificates (I will re-verify this later tonight). It is unclear to
> me where the private keys are in fact stored; and that is my only
> remaining concern.
We'll stay tuned for the certutil output. :-)
--
Nelson B
Dave Pinn
(C) Copyright 1985-2001 Microsoft Corp.
C:\>certutil -L -h "Embedded Security Chip" -d X:/ThunderbirdProfile
Enter Password or Pin for "Embedded Security Chip":
Embedded Security Chip:David Michael Pinn's eSign Australia ID u,u,u
Embedded Security Chip:David Michael Pinn's eSign Australia ID pu,Pu,pu
C:\>
ta-da!
Peter Djalaliev
Nelson Bolyard wrote:
> You generated the key pair on a PC that didn't have the TPM chip.
> So the private key couldn't have been generated in the TPM chip,
> and when you generated it, mozilla (FF/TB/SM) didn't ask you which
> device you wanted to use to generate the keypair because, on that
> machine, there was no choice to be made.
Well, I don't quite understand this, but I think it depends on the way
that the HP developers of the PKCS#11 module implemented this. In
general, the TPM can generate keys. Some of them, the root keys never
ever leave the the TPM - this is partially how trust is achieved.
Other keys can be created by the TPM and can be migratable and
non-migratable. Yet a third kind of keys can be generated externally,
bu t be protected by the TPM (i.e. by one of the keys stored in the
TPM). In this case, the TPM creates a wrapping key and uses it to
protect the user key. Apparently, Dave's key is of this third kind
since his private key was generated by his CA.
Protecting the key in the TPM can get even fancier - a key can be tied
to a values of one or more of the PCR registers in the TPM, i.e. the
key can be used only when the PCR values it is bound to match.
However, I suspect this isn't the case with the HP PKCS#11 module...
Now, how these keys and the corresponding certificates would be made
available in the PLCS#11 module, seems to be up to the module
implementation...
As Wan-Teh, I also wish I had one of these HP-s with the TPM and the
fingerprint reader... I am using the TPMs shipped with some of
IBM/Lenovo's ThinkPads. We are working under Linux and we use the TPM
open-source driver and library developed by IBM. This library provides
a lower-level API, the HP module is probably using something similar.
A question unrelated to NSS, but related to this thread: does anybody
know how Windows provides access to the TPM? The work we do under
Linux restricts access to the device. In general, I think access to
the TPM shouldn't be given to any application (at least not yet)
because the TPM-enabled functionality can be abused - i.e. to lock
document contents to a particular application, etc.
Regards,
Peter
Peter Djalaliev
starting on p. 145 of the TCPA specification (v. 1.1):
https://www.trustedcomputinggroup.org/specs/TPM/TCPA_Main_TCG_Architecture_v1_1b.pdf
Regards,
Peter
Peter Djalaliev
Peter Djalaliev
...and as the ProtectTools implementation white-paper explains, their
Embeded Security Manager uses the TPM to create wrapping keys, which
are then used to encrypt the private keys of the user. The wrapped
keys are then stored on the hard disk.
So, Dave's key (the one generated by his CA) was probably never in the
TPM, but it was wrapped by a key stored in the TPM. I wonder, could
this be why the key could not be found in the PKCS#11 module? The HP
implementation whitepaper makes it clear that:
"The TPM can also protect keys generated outside
ProtectTools Embedded Security. In this case, keys
can be presented to the TPM through either the
CryptoAPI or PKCS#11 interface."
I would guess that these keys can also be accessed through the PKCS#11
interface, but...
Regards,
Peter
Dave Pinn
participation of several dedicated and generous souls in the
investigation of this problem.
It is currently 9:20 pm here in Sydney; I will attempt to contact a
techie at HP tomorrow, to see if I can get some answers.
I posted several messages on the HP support forums, with zero replies,
but maybe I will be more successful by phone.
Dave
Nelson Bolyard
I would expect that these details all go on beneath the PKCS#11 API layer,
and are all hidden inside of the PKCS#11 module. I suspect that the wrapped
keys (wherever they physically reside) still appear as PKCS#11 objects in
the PKCS#11 "slot" or "token", and would be findable through the PKCS#11
C_FindObjects function.
Nelson Bolyard
> Nelson Bolyard wrote:
>
>> You generated the key pair on a PC that didn't have the TPM chip.
>> So the private key couldn't have been generated in the TPM chip,
>> and when you generated it, mozilla (FF/TB/SM) didn't ask you which
>> device you wanted to use to generate the keypair because, on that
>> machine, there was no choice to be made.
>
> Well, I don't quite understand this, but I think it depends on the way
> that the HP developers of the PKCS#11 module implemented this.
Dave told us there were two PCs involved, a desktop PC (of unknown brand
and capabilities), and a notebook PC (the HP with the TPM). I presume
that the desktop PC did not have a TPM, or certainly not THE TPM on his
notebook.
He told us that he went through the process of generating the Certificate
Signing Request (which generates the key pairs) on the desktop PC.
When you generate a CSR/key-pair with mozilla clients, if you have two or
more PKCS#11 slots that are capable of doing it, mozilla will ask you which
to use (IIRC). If you only have one, then mozilla doesn't ask. Dave didn't
report that he was asked, and I think this is because the desktop PC had
only one PKCS#11 module, that being mozilla's own "softoken".
> In general, the TPM can generate keys. Some of them, the root keys never
> ever leave the the TPM - this is partially how trust is achieved.
I'd expect the private and secret ones do not, and the public ones do.
Otherwise, they're not very useful. :)
> Other keys can be created by the TPM and can be migratable and
> non-migratable. Yet a third kind of keys can be generated externally,
> bu t be protected by the TPM (i.e. by one of the keys stored in the
> TPM). In this case, the TPM creates a wrapping key and uses it to
> protect the user key. Apparently, Dave's key is of this third kind
> since his private key was generated by his CA.
I didn't read anything that suggested that he didn't generate his own
private keys.
A week after applying for his certificate, he download the certificate
onto the same desktop box where he had generated the CSR, which combined
the cert and private key in the same mozilla softoken module. Then he
"exported" the cert and private key into a PKCS#12 file, which he then
imported onto the notebook. That's how I read the description.
Dave, if I misunderstood, please jump in here. :)
> Now, how these keys and the corresponding certificates would be made
> available in the PLCS#11 module, seems to be up to the module
> implementation...
Agreed.
Nelson Bolyard
> I need to clarify something: there are two states in which I can have my
> notebook (the one with the TPM):
>
> 1. Certificates directly (via ProtectTools import function) and fully
> (the icons indicate that private keys are available) imported into the
> TPM. This is the state in which I found my machine at the end of the
> certificate purchase process that I described earlier in detail. In this
> state, Thunderbird *cannot* see the certificates; nor can certutil.
Out of idle curiosity, I'd be interested in what NSS's pk11util sees.
But even if I had that information, I couldn't do much with it.
It would be of diagnostic value to the HP folks, but otherwise there's
little I could do about it, even if I knew exactly what it was doing.
> 2. Certificates indirectly (via Thunderbird) imported into the TPM. In
> this state, Thunderbird can see and use the certificates to sign and
> validate signed e-mails; but the icons in the ProtectTools Certificate
> Viewer show that the private key is not available.
I suspect (guess) that this means that the imported private keys are just
that, imported, and therefore the TPM cannot provide any assurances that
there are no copies of these keys elsewhere (which is one of the main
benefits of a TPM, IINM).
> certutil *can* see the certificates (I will re-verify this later tonight).
> It is unclear to me where the private keys are in fact stored; and that
> is my only remaining concern.
/Nelson
Peter Djalaliev
Nelson Bolyard написа:
> I would expect that these details all go on beneath the PKCS#11 API layer,
> and are all hidden inside of the PKCS#11 module. I suspect that the wrapped
> keys (wherever they physically reside) still appear as PKCS#11 objects in
> the PKCS#11 "slot" or "token", and would be findable through the PKCS#11
> C_FindObjects function.
Absolutely, you are right about PKCS#11 (and you know much more about
it than me anyway). I just got a little confused about people talking
about generating private keys in the TPM and taking them out. It seems
that all private keys (thank you for the correction here) generated in
the TPM never leave it, unless they are marked as migratable and are
migrated to another TPM. The corresponding public keys can be exported
:)
Regards,
Peter
Peter Djalaliev
navigate to the CA website and click the "Buy Now" button, not to
generate his own private key and CSR.
Can Firefox generate private keys? I though that none of the NSS
functionality (except for signing and verifying text) was exported to
the rest of the Mozilla platform through XPCOM. I learnt that from
another posting in this mailing list, I believe.
> I didn't read anything that suggested that he didn't generate his own
> private keys.
Yes, I might have been wrong here. But, the point was that the key was
generated outside his TPM (which is the same as what you are saying).
I was trying to go down to the basics and figure out how exactly Dave's
private key got associated with his TPM and why possibly the key
wouldn't be available through PKCS#11.
I think that by now we agree that the key was generated externally (by
Dave or his CA), then Dave got his certificate and imported it to the
ProtectTools utility, which had the TPM generate a wrapping key and
encrypt Dave's key with it. ProtectTools then stored the encrypted key
on the harddisk.
Yes, I agree that if everything works fine, these details should be
hidden by the PKCS#11 API.
Regards,
Peter
Dave Pinn
> A week after applying for his certificate, he download the certificate
> onto the same desktop box where he had generated the CSR, which combined
> the cert and private key in the same mozilla softoken module. Then he
> "exported" the cert and private key into a PKCS#12 file, which he then
> imported onto the notebook. That's how I read the description.
>
> Dave, if I misunderstood, please jump in here. :)
It was as you have described, Nelson. The purchase process took me
through a wizard-like sequence of pages; at one step in that process,
the keys were generated and installed in Firefox. I don't know the
mechanics of how the keys were generated; I assume that it happened in
Firefox, but perhaps they were generated on the GateKeeper (CA) server
and downloaded into Firefox - could a web site initiate key generation
inside Firefox?
In any case, the public and private keys were created on a machine that
had no TPM, and moved to the machine with the TPM as a .p12 file.
Dave
Dave Pinn
> ...It seems
> that all private keys (thank you for the correction here) generated in
> the TPM never leave it, unless they are marked as migratable and are
> migrated to another TPM. The corresponding public keys can be exported
In support of your conclusion: the ProtectTools Certificate Viewer can
export certificates as files; and, even when it considers the private
key to be 'available', it greys out the option of exporting the private
key along with the certificate. The TPM is like the Mafia: when you're
in, you're in.
I think I remember reading that it is possible to transfer a certificate
to another TPM, including the private key, but it requires some kind of
handshake with the target TPM; you cannot export to a file whose
destination is unspecified.
I am perplexed by something: the export-to-file wizard in ProtectTools
offers the user several file formats: DER encoded binary X.509 (.cer),
Base-64 encoded X.509 (.cer), Cryptograhic Message Syntax Standard
(.p7b), and PKCS#12 (.pfx). That last option, the PKCS#12 option, is
always greyed out (unavailable); why? Might it be that .pfx requires
that the private key be exported too?
Dave Pinn
I notice that in one scenario, the one where the private key is marked
'not available' in ProtectTools, there appears a button in the
Certificate Viewer, labelled 'Install Certificate...'.
Naturally, I push the button.
I am led through the Certificate Import Wizard, whose introduction says,
"This wizard helps you copy certificates, certificate trust lists, and
certificate revocation lists from your disk to a certificate store."
I click Next
I am asked to select a system area for storage of the certificate. I
select "Determine automatically based on the type of certificate".
The wizard says, "The import was successful"
I look around to see what has changed. Nothing. Not a thing. The private
keys are still marked as unavailable.
Nelson Bolyard
> Nelson Bolyard wrote:
>> A week after applying for his certificate, he download the certificate
>> onto the same desktop box where he had generated the CSR, which combined
>> the cert and private key in the same mozilla softoken module. Then he
>> "exported" the cert and private key into a PKCS#12 file, which he then
>> imported onto the notebook. That's how I read the description.
>>
>> Dave, if I misunderstood, please jump in here. :)
>
> It was as you have described, Nelson. The purchase process took me
> through a wizard-like sequence of pages; at one step in that process,
> the keys were generated and installed in Firefox. I don't know the
> mechanics of how the keys were generated; I assume that it happened in
> Firefox,
Yes, I'm rather certain it did.
> but perhaps they were generated on the GateKeeper (CA) server
> and downloaded into Firefox - could a web site initiate key generation
> inside Firefox?
Yes. There are two ways to do it: a magic html tag <keygen> and
a javascript method (which is more flexible).
> I am perplexed by something: the export-to-file wizard in ProtectTools
> offers the user several file formats: DER encoded binary X.509 (.cer),
> Base-64 encoded X.509 (.cer), Cryptograhic Message Syntax Standard
> (.p7b), and PKCS#12 (.pfx). That last option, the PKCS#12 option, is
> always greyed out (unavailable); why? Might it be that .pfx requires
> that the private key be exported too?
pfx files are PKCS#12 files, also known as .p12 files.
The PKCS#12 standard does not require that private keys be included.
But the main incentive to use PKCS#12 (as opposed to any of the other
formats you named above) is to be able to transport certs and private
keys together in one package. Most users think of p12 files as being
their private key files. I think most users think that if they can
export their cert into a .p12 file, they will then be able to import
that .p12 file and get both their private key and cert out of it.
So, I imagine the reason that this tool won't let you export a cert
to pfx without the private key is to avoid later confusion when the
user finds there's no private key in his .p12 file.
I believe that Windows' certificate manager does the same thing, not
allowing you to export to a pfx file when the private key has been
marked unexportable.
> I notice that in one scenario, the one where the private key is marked
> 'not available' in ProtectTools, there appears a button in the
> Certificate Viewer, labelled 'Install Certificate...'.
>
> Naturally, I push the button.
>
> I am led through the Certificate Import Wizard, whose introduction says,
> "This wizard helps you copy certificates, certificate trust lists, and
> certificate revocation lists from your disk to a certificate store."
I think it's odd that it says "from your disk". That's pretty vague.
But it's pretty clear to me that the "certificate store" to which it is
referring is Windows' OS aggregated cert store.
> I click Next
>
> I am asked to select a system area for storage of the certificate. I
> select "Determine automatically based on the type of certificate".
Windows has numerous places to store certificates. These are sometimes
known as "physical stores". Some of them are in various places in the
registry. Others are elsewhere. There are stores that are unique to
each user (account) in Windows, and there are stores that apply to the
whole system and all its usres.
Various tools that come with Windows present the aggregated contents of
these stores to the users, as if there was just one store, hiding the
details of which of the "physical stores" really holds each cert or key.
But when you go to put a cert into the store, you (or some software)
has to actually pick one of the physical stores to hold it.
> The wizard says, "The import was successful"
>
> I look around to see what has changed. Nothing. Not a thing. The private
> keys are still marked as unavailable.
I'll bet that if you look in Windows' cert store with Windows cert manager,
you will find your cert there now, but would not have before doing this.
You could probably delete your cert from Windows cert store, and then
go through this process again, and see it return.
Windows cert manager is a dialog you get to from within IE,
Tools -> Internet Options -> Content (tab) -> Certificates (button)
Arshad Noor
key; and since your TPM does not allow the export of private keys,
this option should be unavailable for certificates which have
corresponding private keys.
All other formats in your list do not include private keys.
Arshad Noor
StrongAuth, Inc.