[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: isakmpd and reading x509 certs



If you have it talking to windows XP it's unlikely you
have things real wrong.  But, if you think there's a question,
To check your CA's key for sanity:
	openssl rsa -check -in /etc/ssl/private/ca.key -noout

To see the public key in your cert & from the private key file, try:
	openssl x509 -in /etc/ssl/private/ca.crt -pubkey -noout
	openssl rsa -in /etc/ssl/ca.crt -pubout

To review your certificate including all options,
	openssl x509 -in ca.crt -noout -text
Posting this is probably more useful than posting how you made
your certificate; for instance, your x509v3.cnf appears to be looking
in your environment for $CERTPATHLEN and $CERTUSAGE which you neglected
to tell us.  Also, you must have done an "openssl genrsa" command
beforehand even though you didn't say so.  It's possible to collapse
your 3 genrsa/req/x509 commands down to one command doing something
like this:
	openssl req -x509 -new -out ca2.crt -nodes -keyout ca2.key -newkey rsa:1024
but I don't think that's going to make any difference for you.

The sequence you posted appears to be intended to create a
self-contained certificate authority with one self-signed certificate.
Are you trying to use that directly, or are you creating additional
certificates using it?

With isakmpd - I'm not real familiar with it, but I think I know how
it "should" be using x509 certificates -- I would expect that
each end should have:
	list of CA certificates for authorities it will trust as
		signers (directly or indirectly) for certs from
		the other end.
	0 or more of:
	{
		CA certificate chain above its own certificate
		its own certificate
		its own private key
	} - 0 or more of these

In use, I presume isakmp has some sort of negotiation protocol that
involves receiving a list of certificate authorities the other side
trusts, selecting a local private key & certificate, using that to sign
something, and sending the signature, its own certificate, and a
possibly empty chain of certificate authorities connecting its own
certificate to whatever the other end claims to trust back to the other
side.  At least, that's (more or less) how ssl works, although in
practice usually only the web server has a certificate.

The list of remote signers that each end trusts does not have to
include whatever signed its own certificates.  I think I've seen
inconsistent windows behavior regarding the CA chain for any local
certificate+private keys: sometimes it seems to want to have that
chain, sometimes it does not.  The openssl equivalent to this is the
"verify" command, but I don't know if windows even makes anything
like this functionality accessible from a comand-line interface.

				-Marcus Watts