[Openvpn-users] use pkcs12 certificates or not

[John]

Hello list,

Can somebody explain to me (and the rest of the list, if interested) if the
use of pkcs12 certificates is better or not better / safer /handier / better
manageable as the ca, cert and key directives in the openvpn configuration
files ?

I understand it so far:
You can convert a existing key pair to a (binary) pkcs12 certificate, where
the pkcs12 combines the ca, crt and key in one file.
I've got this from the openvpn man page:
--pkcs12 file
Specify a PKCS #12 file containing local private key, local certificate, and
root CA certificate. This option can be used instead of --ca, --cert,
and --key.
If you passwd protect the exported key, the whole pkcs12 key is encrypted
with that passwd.

Is this passwd similar to passwd protected key of the build-key-pass script?
Can the pkcs12 passwd changed in the same way as a normal key can be done? I
red somewhere that you can't change the export passwd of pkcs12 key.
I hope somebody can some light on this.


Regards,
John Knappers
The Netherlands

[Mathias Sundman]

Post by John
Hello list,
Can somebody explain to me (and the rest of the list, if interested) if the
use of pkcs12 certificates is better or not better / safer /handier / better
manageable as the ca, cert and key directives in the openvpn configuration
files ?

I don't believe there is any diffrence from a security perspective to use
a PKCS12 file or individual files. I find it more convenient to use
PKCS#12 files as there is only a single file to distribute.

If you do it the "right way" and have your users create a certificate
request which you sign and return to the user, it might be more convenient
to use seperate files though as the user would otherwise have to do the
merge of the files into a pkcs12 file on the client.

Post by John
You can convert a existing key pair to a (binary) pkcs12 certificate, where
the pkcs12 combines the ca, crt and key in one file.
--pkcs12 file
Specify a PKCS #12 file containing local private key, local certificate, and
root CA certificate. This option can be used instead of --ca, --cert,
and --key.
If you passwd protect the exported key, the whole pkcs12 key is encrypted
with that passwd.
Is this passwd similar to passwd protected key of the build-key-pass script?

Yes the encryption is similar. I think the default algoritm is to use 3DES
for encrypting both pem files and pkcs12 files.

Post by John
Can the pkcs12 passwd changed in the same way as a normal key can be done? I
red somewhere that you can't change the export passwd of pkcs12 key.

Well - you can never "change" the password, but just as you can un-encrypt
a private key (.pem) file and then re-encrypt it using another passphrase,
you can do the same with a p12 file.

You can use the openssl command line utility todo this and OpenVPN GUI
for Windows is capable of "changing password" of both .pem and .p12 files.

/Mathias

[Alon Bar-Lev]

Hello,

Post by John
Hello list,
Can somebody explain to me (and the rest of the list, if interested) if the
use of pkcs12 certificates is better or not better / safer /handier / better
manageable as the ca, cert and key directives in the openvpn configuration
files ?

PKCS#12 is a standard data structure that contains private key and a
set of certificates. It is more convenient to store key and
certificate in the same file so it is easy to use PKCS#12.

Also, PKCS#12 can be imported and exported to other environments as
Microsoft store and Java. So if you have PKCS#12 you can be sure that
you can use your resources in most environments.

You can always convert key+cert into PKCS#12 and vise-verse so you lose nothing.

THE PROBLEM with openvpn is that it uses the CA certificate from the
PKCS#12 instead of using --ca option, this is none standard use of
PKCS#12 since the CA is used to verify the peer certificate.

I would have expected openvpn uses the end certificate and key from
the PKCS#12 and have a --ca option to load the trust from. To be more
precise I expect openvpn to support several root certificate
authorities and have --cadir option to refer the location of a
directory where these certificates are stored.

Regarding the change password, you can always use 'openssl pkcs12'
command in order to import and export the PKCS#12 using different
password.

To summarize... If openvpn will stop using the CA from the PKCS#12 I
would suggest to use PKCS#12 since it is much more portable and easy
than using cert+key.

Best Regards,
Alon Bar-Lev.

[Mathias Sundman]

Post by Alon Bar-Lev
THE PROBLEM with openvpn is that it uses the CA certificate from the
PKCS#12 instead of using --ca option, this is none standard use of
PKCS#12 since the CA is used to verify the peer certificate.
I would have expected openvpn uses the end certificate and key from
the PKCS#12 and have a --ca option to load the trust from. To be more
precise I expect openvpn to support several root certificate
authorities and have --cadir option to refer the location of a
directory where these certificates are stored.
...
To summarize... If openvpn will stop using the CA from the PKCS#12 I
would suggest to use PKCS#12 since it is much more portable and easy
than using cert+key.

...

Interesting. I wrote the original patch for OpenVPN that added pkcs12
support, and in my "small" world I thought it was most convenient to also
load the trust CA cert(s) from the pkcs12 file. I believe it's possible to
add a chain of CA certs into a pkcs12 file and have that loaded in
openvpn, but I've never heard about anyone testing this.

This is the first time I've heard anybody ask for being able to load the
ca cert seperately from the pkcs12 file. I think it should be a pretty
trivial patch to allow --ca to be used together with --pkcs12, so if you
beleave this is a showstopper I can try putting something together...

Supporting multiple root CAs and --cadir is a little bit more work so I
leave that to someone else who needs it to work on...

If you only have one ca root cert, why do you dislike having that bundled
in the pkcs12 file?

[Alon Bar-Lev]

Post by Mathias Sundman
Interesting. I wrote the original patch for OpenVPN that added pkcs12
support, and in my "small" world I thought it was most convenient to also
load the trust CA cert(s) from the pkcs12 file.

The problem in this implementation is that the CA you load from the
PKCS#12 is used in order to validate a resource that is not in the
PKCS#12. This is a conceptual problem... doing so is none standard,
since the identity and trust are two separate issues.

Post by Mathias Sundman
This is the first time I've heard anybody ask for being able to load the
ca cert seperately from the pkcs12 file. I think it should be a pretty
trivial patch to allow --ca to be used together with --pkcs12, so if you
beleave this is a showstopper I can try putting something together...
If you only have one ca root cert, why do you dislike having that bundled
in the pkcs12 file?

I think you should remove the establishment of trust from the
PKCS#12... So that it won't be a security weakness.... let's say I
give the user write access the the PKCS#12 file so he can update his
identity, in current implementation the user can also affect the
identity of the remote server... This should not be possible.

The trust must be separated from the identity.

Post by Mathias Sundman
Supporting multiple root CAs and --cadir is a little bit more work so I
leave that to someone else who needs it to work on...

I thought of doing this my-self... But I need to finish my PKCS#11 patch first.

Best Regards,
Alon Bar-Lev.

[Mathias Sundman]

Post by Alon Bar-Lev

Post by Mathias Sundman
Interesting. I wrote the original patch for OpenVPN that added pkcs12
support, and in my "small" world I thought it was most convenient to also
load the trust CA cert(s) from the pkcs12 file.

The problem in this implementation is that the CA you load from the
PKCS#12 is used in order to validate a resource that is not in the
PKCS#12. This is a conceptual problem... doing so is none standard,
since the identity and trust are two separate issues.

Post by Mathias Sundman
This is the first time I've heard anybody ask for being able to load the
ca cert seperately from the pkcs12 file. I think it should be a pretty
trivial patch to allow --ca to be used together with --pkcs12, so if you
beleave this is a showstopper I can try putting something together...
If you only have one ca root cert, why do you dislike having that bundled
in the pkcs12 file?

I think you should remove the establishment of trust from the
PKCS#12... So that it won't be a security weakness.... let's say I
give the user write access the the PKCS#12 file so he can update his
identity, in current implementation the user can also affect the
identity of the remote server... This should not be possible.
The trust must be separated from the identity.

...

I see the problem, but I also see the convenience of only having to
distribute one file containing everything.

I think allowing --ca to overide the load of CA cert from a pkcs12 file
ought to be good enough for both scenarios. If you add --ca to the config
file, that will always be used to specify what ca cert to use, and if you
use file permissions to control that the user can't modify the ca cert
file, you can also restrict the user from editing the config file itself.

Post by Alon Bar-Lev

Post by Mathias Sundman
Supporting multiple root CAs and --cadir is a little bit more work so I
leave that to someone else who needs it to work on...

I thought of doing this my-self... But I need to finish my PKCS#11 patch first.

Great! Supporting multiple root certs is a pretty cool feature, especially
if you think about how you can then use it in a client-connect script to
give diffrent access right depending on what CA the user belonged to.

[Alon Bar-Lev]

Post by Mathias Sundman
I think allowing --ca to overide the load of CA cert from a pkcs12 file
ought to be good enough for both scenarios. If you add --ca to the config
file, that will always be used to specify what ca cert to use, and if you
use file permissions to control that the user can't modify the ca cert
file, you can also restrict the user from editing the config file itself.

I don't agree... But I am willing to accept that...
I still think you should separate the trust and identity...

Post by Mathias Sundman
Great! Supporting multiple root certs is a pretty cool feature, especially
if you think about how you can then use it in a client-connect script to
give diffrent access right depending on what CA the user belonged to.

I don't know enough of this interface... I think the script does not
get the whole certificate... And the interface should not be
changed... So I don't think it will be possible, and if it gets the
whole certificate it can parse it and know who issued it.

Best Regards,
Alon Bar-Lev.

[Mathias Sundman]

Post by Alon Bar-Lev

Post by Mathias Sundman
I think allowing --ca to overide the load of CA cert from a pkcs12 file
ought to be good enough for both scenarios. If you add --ca to the config
file, that will always be used to specify what ca cert to use, and if you
use file permissions to control that the user can't modify the ca cert
file, you can also restrict the user from editing the config file itself.

I don't agree... But I am willing to accept that...

Well, we don't have to agree on everything ;-)

Post by Alon Bar-Lev
I still think you should separate the trust and identity...

If I were to write the pkcs12 support now after this díscussion I'd
propably have made it like you say, but now when the feature (or security
issue as you look at it) already exists, it's a little harder to just
remove it.

I guess we'll need more feedback from people using it.

Post by Alon Bar-Lev

Post by Mathias Sundman
Great! Supporting multiple root certs is a pretty cool feature, especially
if you think about how you can then use it in a client-connect script to
give diffrent access right depending on what CA the user belonged to.

I don't know enough of this interface... I think the script does not
get the whole certificate... And the interface should not be
changed... So I don't think it will be possible, and if it gets the
whole certificate it can parse it and know who issued it.

...

I havn't looked at the interface in detail either, I just ment that it
opens up some possibilities even if requires some changes also to other
parts of the code...

[Alon Bar-Lev]

Post by Mathias Sundman
If I were to write the pkcs12 support now after this díscussion I'd
propably have made it like you say, but now when the feature (or security
issue as you look at it) already exists, it's a little harder to just
remove it.

Will you make the change (--ca overrides the read of CA from the PKCS#12)?

Alon

[Mathias Sundman]

Post by Alon Bar-Lev

Post by Mathias Sundman
If I were to write the pkcs12 support now after this díscussion I'd
propably have made it like you say, but now when the feature (or security
issue as you look at it) already exists, it's a little harder to just
remove it.

Will you make the change (--ca overrides the read of CA from the PKCS#12)?

Yes, I can fix that, unless someone thinks that's a bad thing. I can't see
anything bad with it at least. James, any comments?

[John]

Post by Alon Bar-Lev
Will you make the change (--ca overrides the read of CA from the PKCS#12)?

Yes, I can fix that, unless someone thinks that's a bad thing. I can't see
anything bad with it at least. James, any comments?
--
Nice to see when a simple user question, gives a nice discussion between
developers. :)



It's maybe a good idea to add your explanation and part of the discussion to
the easy-rsa how-to. I'm probably not the only user who get's confused about
the different kind of certificates. Thanks for the explanation.

John Knappers
The Netherlands







_____________________________________________________________
Mathias Sundman (^) ASCII Ribbon Campaign
OpenVPN GUI for Windows X NO HTML/RTF in e-mail
http://openvpn.se/ / \ NO Word docs in e-mail

[James Yonan]

=20

If I were to write the pkcs12 support now after this d=EDscussion I'd
propably have made it like you say, but now when the feature (or secur=

ity

issue as you look at it) already exists, it's a little harder to just
remove it.

Will you make the change (--ca overrides the read of CA from the PKCS#=

12)?

=20
Yes, I can fix that, unless someone thinks that's a bad thing. I can't se=

e=20

anything bad with it at least. James, any comments?

Notwithstanding the issues of identity vs. trust, most people are using
PKCS#12 as a kind of zip/archive file containing certs/keys. I'm not
clear on what the argument is for why security would be affected by the=20
way the files are packaged?

James

[Alon Bar-Lev]

Post by James Yonan

Post by Mathias Sundman

Post by Alon Bar-Lev
Will you make the change (--ca overrides the read of CA from the PKCS#12)?

Yes, I can fix that, unless someone thinks that's a bad thing. I can't see
anything bad with it at least. James, any comments?

Notwithstanding the issues of identity vs. trust, most people are using
PKCS#12 as a kind of zip/archive file containing certs/keys. I'm not
clear on what the argument is for why security would be affected by the
way the files are packaged?

...

This is not a technical issue. Of course you can use PKCS#12 as the
only resource.
This is a conceptual issue.

The CA inside the PKCS#12 uses to verify the peer certificate and not
the certificate in-side the PKCS#12 file... So it is wrong to put two
unrelated resources into the same package. The certificate collection
in-side the PKCS#12 were ment to hold the certificate chain of the end
certificate the PKCS#12 refers to.

Another issue is that openvpn does not support more than one CA so it
makes it difficult to use it in large environments, without issuing a
specific certificate for this purpose. I suggest you consider adding
--cadir that refer to a apache style directory of many certificate
authorities to trust.

I can also correlate between PKCS#12 and a smartcard, both containing
identities (Certificate and private key). Now, the question is whether
I should store the CA on the smartcard as well?

Since there should be a policy of the installation which peers to
trust, this policy cannot be broken by the user if he adds a new CA to
his card. This can also happen by application without the knowledge of
the user. Adding a new CA to the card will cause the software to trust
invalid peer.

There should be a separation between the two resources: trust and
identity. They should not be related. Trust may be changed by system
administrator, Identity can be changed by user.

You can look at other applications that uses PKCS#12, all that I know
(except of openvpn) uses PKCS#12 for identity only, there are some
that can use PKCS#12 for trust, but then you need to specify it
explicitly.

In order to be backward compatible I accept that without --ca option
you continue the current behavior, but if --ca (or future --cadir)
option is given, it should use the PKCS#12 for identity only.

I hope I was clear enough.

Best Regards,
Alon Bar-Lev.