Re: Need pointers on managing client certs...
From: Colin McKinnon (colin.deletethis_at_andthis.mms3.com)
Date: 06/06/05
- Next message: kdd21_at_hotmail.com: "Re: Need pointers on managing client certs..."
- Previous message: kdd21_at_hotmail.com: "Need pointers on managing client certs..."
- In reply to: kdd21_at_hotmail.com: "Need pointers on managing client certs..."
- Next in thread: kdd21_at_hotmail.com: "Re: Need pointers on managing client certs..."
- Reply: kdd21_at_hotmail.com: "Re: Need pointers on managing client certs..."
- Reply: kdd21_at_hotmail.com: "Re: Need pointers on managing client certs..."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Mon, 06 Jun 2005 15:05:29 +0100
kdd21@hotmail.com wrote:
>
> I'm in the process of converting an application that currently uses
> dialup to handle secure transactions to an internet https based
> protocol. I have no control over the server side, just the client
> which is a Unix box. I've been exploring openssl and curl, and trying
> to figure out what is necessary in managing the certificate on the
> client side which appears to be subject to periodic expiration. I can
> get things to work simply by just telling curl not to do certificate
> verification (curl -k), but since there is in fact a certificate it
> would seem prudent not to do that.
>
Yup - not a good idea. You should start by telling curl where to find the CA
certs it needs to verify the remote server ( --cacert / --capath) make sure
you've got the root CA in your install (don't copy it from a server you
want to verify). Next time try checking the exit code of curl.
> trying
> to figure out what is necessary in managing the certificate on the
> client side which appears to be subject to periodic expiration
Does the application require a client side certificate? (Unusual but not
unheard of). What do you mean by "periodic expiration" ? Certificates are
usually only valid for a year or two.
IIRC updating the local CRL should just be a matter of dropping the
published CRL file into whatever openssl.cnf defines as crl_dir. Again,
IIRC, OCSP is built into later versions of openssl. If 'man ocsp' doesan't
turn up anything then you're probably running too old a version of openssl.
WARNING the openssl code has had a number of vulnerabilities over recent
years and for a secure sstem you MUST make provision for patching.
> But basically, I think I
> can manually put together a cert file that will make curl happy, but
> what do I do in six months when it expires?
Three possibilities:
1) you don't really require a client certificate
2) you create a client certificate signed with your own self-sgned root CA
(unless the server has a copy of the public root CA this has no benefits
over 1 above) in which case you can choose how long it's valid for.
3) you are being supplied with a certificate - in which case you don't have
much choice in the matter.
HTH
C.
- Next message: kdd21_at_hotmail.com: "Re: Need pointers on managing client certs..."
- Previous message: kdd21_at_hotmail.com: "Need pointers on managing client certs..."
- In reply to: kdd21_at_hotmail.com: "Need pointers on managing client certs..."
- Next in thread: kdd21_at_hotmail.com: "Re: Need pointers on managing client certs..."
- Reply: kdd21_at_hotmail.com: "Re: Need pointers on managing client certs..."
- Reply: kdd21_at_hotmail.com: "Re: Need pointers on managing client certs..."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
