[vpn-help] Cert q's

[Peter Eisch]

On 8/31/06 11:49 PM, "Matthew Grooms" <mgrooms at shrew.net> wrote:

> Peter Eisch wrote:
>> 
>> On to certificates.  I mentioned last week that I'd like to use p12 cert
>> bundles which include the ca.crt the client's cert and key.  Is there a way
>> to just load a p12 and have the client unbundle the three components when
>> {,xauth-}rsasig is selected?  Specifically, in the tab for certs there would
>> just be one input box to select the path of the p12 and perhaps a radio
>> button to select p12 or discreet files.  Whenever the p12 path changes,
>> there would need to be a password panel that pops up to prompt for the
>> password.  I'd guess that the client could save "import" the cert parts into
>> the certs directory out of the p12 and not store the p12 per se.
>> 
> 
> I follow you all the way up until the p12 password panel. Do you mean a
> password to read an encrypted p12 file? You will have to forgive me. I
> built the p12 cert handlers quite some time ago after Yvan from the
> ipsec-tools team suggested it would be a good thing to have support for.
> 
> It should be possible to specify the same p12 file for all three
> credential file paths. I chose this compromise as I wanted to keep the
> interface simple and not be too p12 specific.
> 

Yes, the p12s, as I build them, contain all three credentials.

openssl pkcs12 -nodes -export -in ${OPENSSL}/certs/${SYSTEM}.crt -inkey \
     ${OPENSSL}/certs/${SYSTEM}.key -certfile ${OPENSSL}/certs/ca.crt \
     -out ${OPENSSL}/certs/${SYSTEM}.p12 -name "Certificate for ${SYSTEM}"

At which point I insert a unique password when prompted.

OS X's Keychain Manager requires p12s to have a password, Windows can go
either way, the cisco client and concentrators can go either way as well.

I hadn't seen anything in ipsec-tools that took p12s.  I'll have to look
more into that as I've been using discreet files on the servers so far.  If
I can use p12s there as well, I'll jump on it and not look back.

Perhaps it's sufficient to just separate the parts of the p12 for future
use.  I know some PKI folks who frown on keys just laying out, unprotected.
In their opinion keys should always be protected by some password or special
security that keeps people without explicit permission from having any
access to them.  A cert store of some sort would be a requirement for the.
With XP and OS X you get this from the host OS (for better or worse) but it
is out of your hands at that point.  Having a cert store that is native to
the client would be more portable and potentially offer the same level of
security to the PKI zealots.

...
> I had thought about storing the cert information in the site
> configuration file when exported. Then on import, the client would dump
> the cert info back out into discrete files. This would be a better for
> pre-configured client installations so the cert doesn't have to be
> bundled like you do at present.
> 
> http://www.shrew.net/vpn/help-1.1/preconfiguredinstalls.htm
> 
> For non MS platforms, the config file will be *the* data storage format
> for site configuration.
> 
> If an admin plans on distributing certs for vpn authentication, I don't
> see why they would raise an objection to how the cert is packaged unless
> its a question of the container format offering another level of
> encryption. After all, for hybrid auth its just some asn1 string and
> public key data that can only be used to authenticate a message
> encrypted with the servers private key. For mutual authentication,
> things get a bit more complicated because of the private key
> distribution. In either case, the distributed key is only as safe as the
> distributed password used to decrypt the key when the client is in use.
> 

How about a scenario where the curmudgeon system administrator wishes to
issue a cert to each device (er, notebook) at the company.  In order to get
at company resources (printers, file shares, etc.) you must have the VPN
(mutual-rsasig) up.  If a situation arises where a specific computer should
not have access to any company resources (termination, theft, etc.) the
admin would like to disable the device.  The admin loaded these certs so
they can't be exported and used on a different system -- he doesn't trust
his users.  Users still need their NT Domain authentication to access the
resources, but that rides over the VPN.

It could be that requirement for not being able to export the cert is
overrated.  I'm not aware, nor have I really sought out, how to export a
cert that Windows loaded with the property of prohibiting re-exporting the
cert, key or CA cert.  Just the same, the users of the cert don't need to
know the p12 password to use it.

> Maybe that can be sent via an ipsec tunnel ;)
> 

Sure, but how do I really know that the person pulling it over the tunnel is
really supposed to have it?  Just so long as it's not java, I guess I'm
happy...

peter