Board index » delphi » Private key formats

Private key formats

Hi all,

I'm writing a HTTPS client and want to do client authentication. So, I have
to set the CertFile property and the KeyFile property of a
ConnectionInterceptOpenSSL. I generated a client authentication certificate
with W2K certificate authority. So I have a private key file of which I
don't know the format and I have a DER encoded certificate which I converted
to PEM encoded using openssl. Indy raises an exception:
"Could not load key, check password". The password I automatically enter in
"onGetPassword" is correct so I think the problem is in the format of my
primary key file. Does anyone know which format indy wants, which format MS
Certificate Services produces or what else might be the problem?

Thanks in advance, Regards,

Bas de Gier

 

Re:Private key formats


Bas,

Quote

> I'm writing a HTTPS client and want to do client authentication. ...
> ... Does anyone know which format indy wants, which format MS
> Certificate Services produces or what else might be the problem?

I haven't used "W2K certificate authority", but Windows certificate
generation
scenario would go like that:

1) you run a software that generates private/public key pair inside
the computer's CSP (cryptographic security provider AS PER MS); the
key
pair is stored "inside CSP", which means "somewhere there" (could be
in registry,
could be in some file, in AD or on a security card and so on; but it
is "assured"
by CSP vendor to be "sufficiently secure") and is "normally"
accessible by
current user only; also to make my point, you can set "NON-EXPORTABLE"
flag, which means you can use the key pair, but you won't be able to
export
it out of that computer's CSP IN ANY FORM - it is there inside that
computer
forever <g>;

2) you run another software that uses the generated on step 1) key
pair to generated a CR (certificate request); CR is a peace of data
that consist
of public key (from the key pair), some fields describing requested
certificate
subject attributes (name and so on) and signature (generated by
signing CR
(public key and fields) with private key from the key pair);

3) you send CR to a certificate authority and receive a certificate
back in return;

4) you use the certificate, and if asked to prove your ownership (as
it would
happend when you do client authentication) you have to get to your key
pair
which is inside your competer's CSP.

If you followed all that you understand that in windows private/public
key pairs
are stored hidden inside CSP and you must use wincrypt API to get them
out
of it. There are CryptExportKey/CryptImportKey functions that do that
but they are just help each other to move kay pairs between computers
and
there is no docs as to format of key pair BLOBs they generate (these
are
encrypted of course).

The only "simple enough" way I know of is to install your certificate
into
your computer's certificate store first and make sure it finds the
private key for it,
then take an option to export the certificate WITH PRIVATE KEY, and
that will
create a ".PFX" file that hopefully you would be able to import into
OpenSSL,
see http://www.drh-consultancy.demon.co.uk/pkcs12faq.html for that for
example.

Another alternative would be to use MS tools instead for your program,
I've
played with them and they work quite well.

Alex

Re:Private key formats


Alex,

First of all, thanks for your reaction. The theory is clear but I still have
my practical problem. When I send a CR to the CA, I can choose to generate a
keyfile (maybe this is only possible with that CA software in W2K). I have
to give a password and the encrypted keyfile is generated. So there must be
some format of storing keys in files. Indy has this property "KeyFile" and
it has an onPassword event, asking to give the password that encrypted the
primary key, so indy indeed expects a private key file. Though, it can't use
the generated keyfile.
I also tried exporting a certificate out of the store, to .PFX format. This
worked fine. With OpenSSL I can output certificate(s) (all certificates in
the certificate path) without the private key. I also managed to get the
private key out of it, without certificates. Though, also this keyfile could
not be read by Indy.

I'm really getting desperated, there must be somebody out there that managed
to get client authentication out of those indy components...

Regards,
Bas de Gier

Quote
"Alex Brainman" <brain...@sussan.com.au> wrote in message

news:3b4ce248_1@dnews...
Quote
> Bas,

> > I'm writing a HTTPS client and want to do client authentication. ...
> > ... Does anyone know which format indy wants, which format MS
> > Certificate Services produces or what else might be the problem?

> I haven't used "W2K certificate authority", but Windows certificate
> generation
> scenario would go like that:

> 1) you run a software that generates private/public key pair inside
> the computer's CSP (cryptographic security provider AS PER MS); the
> key
> pair is stored "inside CSP", which means "somewhere there" (could be
> in registry,
> could be in some file, in AD or on a security card and so on; but it
> is "assured"
> by CSP vendor to be "sufficiently secure") and is "normally"
> accessible by
> current user only; also to make my point, you can set "NON-EXPORTABLE"
> flag, which means you can use the key pair, but you won't be able to
> export
> it out of that computer's CSP IN ANY FORM - it is there inside that
> computer
> forever <g>;

> 2) you run another software that uses the generated on step 1) key
> pair to generated a CR (certificate request); CR is a peace of data
> that consist
> of public key (from the key pair), some fields describing requested
> certificate
> subject attributes (name and so on) and signature (generated by
> signing CR
> (public key and fields) with private key from the key pair);

> 3) you send CR to a certificate authority and receive a certificate
> back in return;

> 4) you use the certificate, and if asked to prove your ownership (as
> it would
> happend when you do client authentication) you have to get to your key
> pair
> which is inside your competer's CSP.

> If you followed all that you understand that in windows private/public
> key pairs
> are stored hidden inside CSP and you must use wincrypt API to get them
> out
> of it. There are CryptExportKey/CryptImportKey functions that do that
> but they are just help each other to move kay pairs between computers
> and
> there is no docs as to format of key pair BLOBs they generate (these
> are
> encrypted of course).

> The only "simple enough" way I know of is to install your certificate
> into
> your computer's certificate store first and make sure it finds the
> private key for it,
> then take an option to export the certificate WITH PRIVATE KEY, and
> that will
> create a ".PFX" file that hopefully you would be able to import into
> OpenSSL,
> see http://www.drh-consultancy.demon.co.uk/pkcs12faq.html for that for
> example.

> Another alternative would be to use MS tools instead for your program,
> I've
> played with them and they work quite well.

> Alex

Re:Private key formats


Bas,

"Bas de Gier" <bdeg...@inad.nl> wrote in message
news:3b4d54cf_1@dnews...

Quote

>... When I send a CR to the CA, I can choose to generate a
> keyfile (maybe this is only possible with that CA software in W2K).
I have
> to give a password and the encrypted keyfile is generated. So there
must be
> some format of storing keys in files.

Forget that, it would be something that no one knows about ...

Quote
> Indy has this property "KeyFile" and
> it has an onPassword event, asking to give the password that
encrypted the
> primary key, so indy indeed expects a private key file. Though, it
can't use
> the generated keyfile.

As I said just before, forget that path.

Quote
> I also tried exporting a certificate out of the store, to .PFX
format. This
> worked fine. With OpenSSL I can output certificate(s) (all
certificates in
> the certificate path) without the private key. I also managed to get
the
> private key out of it, without certificates. Though, also this
keyfile could
> not be read by Indy.

You are very close in here. I haven't used Indy and don't know the
file formats,
but I would assume you would need a file with client certificate
itself:

openssl pkcs12 -in test.pfx -passin pass:testin -nokeys -clcerts

that should work no problem, and you should get something like that
(get rid of all headers before "BEGIN CERTIFICATE" line

-----BEGIN CERTIFICATE-----
...
...
-----END CERTIFICATE-----

also the private key:

openssl pkcs12 -in c:\tmp\test.pfx -passin pass:testin -passout
pass:testout -nocerts

this should generate private key blob, like that

-----BEGIN RSA PRIVATE KEY-----
...
...
-----END RSA PRIVATE KEY-----

Than, I guess, you should use "testout" as password in your onPassword
event.

But all that said, if you've got PKCS#12 (.pfx) file out of windows,
then you
should be able to use openssl pkcs12 to get everything you need out of
it ...

Quote

> I'm really getting desperated, there must be somebody out there that
managed
> to get client authentication out of those indy components...

Pass. I've done that with MS SSPI, but not with Indy.

Alex

Re:Private key formats


Hi Alex,

Thanks for all your information. Yesterday I've continued to fight with the
problem and I managed to solve it, now I read your post and you're right
about your solution. I did it a little bit different but the main problem
was cutting out the header files of the private key file. Indy wants a file
containing just the

-----BEGIN CERTIFICATE-----
...
...
-----END CERTIFICATE-----

- part, just like you said. I really don't understand why they didn't add a
line of comment or documentation somewhere, it would have made the last few
days a lot easier for me ;)
Anyway, thanks a lot, it works now!

Regards,
Bas

Quote
"Alex Brainman" <brain...@sussan.com.au> wrote in message

news:3b4e5843_2@dnews...
Quote
> Bas,

> "Bas de Gier" <bdeg...@inad.nl> wrote in message
> news:3b4d54cf_1@dnews...

> >... When I send a CR to the CA, I can choose to generate a
> > keyfile (maybe this is only possible with that CA software in W2K).
> I have
> > to give a password and the encrypted keyfile is generated. So there
> must be
> > some format of storing keys in files.

> Forget that, it would be something that no one knows about ...

> > Indy has this property "KeyFile" and
> > it has an onPassword event, asking to give the password that
> encrypted the
> > primary key, so indy indeed expects a private key file. Though, it
> can't use
> > the generated keyfile.

> As I said just before, forget that path.

> > I also tried exporting a certificate out of the store, to .PFX
> format. This
> > worked fine. With OpenSSL I can output certificate(s) (all
> certificates in
> > the certificate path) without the private key. I also managed to get
> the
> > private key out of it, without certificates. Though, also this
> keyfile could
> > not be read by Indy.

> You are very close in here. I haven't used Indy and don't know the
> file formats,
> but I would assume you would need a file with client certificate
> itself:

> openssl pkcs12 -in test.pfx -passin pass:testin -nokeys -clcerts

> that should work no problem, and you should get something like that
> (get rid of all headers before "BEGIN CERTIFICATE" line

> -----BEGIN CERTIFICATE-----
> ...
> ...
> -----END CERTIFICATE-----

> also the private key:

> openssl pkcs12 -in c:\tmp\test.pfx -passin pass:testin -passout
> pass:testout -nocerts

> this should generate private key blob, like that

> -----BEGIN RSA PRIVATE KEY-----
> ...
> ...
> -----END RSA PRIVATE KEY-----

> Than, I guess, you should use "testout" as password in your onPassword
> event.

> But all that said, if you've got PKCS#12 (.pfx) file out of windows,
> then you
> should be able to use openssl pkcs12 to get everything you need out of
> it ...

> > I'm really getting desperated, there must be somebody out there that
> managed
> > to get client authentication out of those indy components...

> Pass. I've done that with MS SSPI, but not with Indy.

> Alex

Re:Private key formats


"Bas de Gier" <bdeg...@inad.nl> wrote in message news:3b4ea366$1_2@dnews...

Quote
> . I really don't understand why they didn't add a
> line of comment or documentation somewhere, it would have made the last
few
> days a lot easier for me ;)

Look at it from the positive side: I'm sure <g> you've learned
quite a lot along the way ...

Alex

Other Threads