"Lee Dilkie" writes:
> you didn't look at the certificate fully. there is also
>
> RFC822 [EMAIL PROTECTED]
> RFC822 [EMAIL PROTECTED]
> RFC822 [EMAIL PROTECTED]
> in the Subject Alternative Name as rfc3280 requires.
That is very clever of them! I have been meaning to test your cert consruction
"Lee Dilkie" writes:
> Mine works fine.
In a sense.
E = [EMAIL PROTECTED], E = [EMAIL PROTECTED], E = [EMAIL PROTECTED], CN = Thawte
Freemail Member
rfc 3280
http://www.ietf.org/rfc/rfc3280.txt
p 23-24, section 4.1.2.6 Subject
In addition, legacy implementations exist where an RFC 822 name
Joseph Bruni writes:
> -- call "curl" or "wget" to retrieve the CRL
> -- use "openssl crl -nextupdate ..." to extract the update time
> -- call "at" to schedule itself to run again in the future.
Here are some other things that would be worth taking into consideration.
In downloaded crl's:
Look f
t; process?
>
> Exactly. Security is all about risk management. Which is more likely ...
> If you really care, have your CA issue a CRL-issuing-certs to someone else.
[believe that's an indirect crl]
A well known openssl personage writes (in a private response to me):
> On Sun,
> > I have the following scenario -
> >
> > Client Cert -- Tunnel Server - Tunnel Client -- Backend server.
> >
> > The requirement is to pass the Client Cert to the Backend server.
> If you could do that then anyone who had access to a certificate
> (for example the recipent of signed emai
Mikhail Sandler writes:
> Is there a way to automate the process of importing a certificate file
> into IE? The current way that I am using involves going to
> 'internet options' and importing a certificate file from the certificates
Are you looking for a customer-driven online solution
(eg, cl
Bodo Moeller writes:
> library still builds the chain automatically when the CA certificate
> is also configured as a trusted certificate for client authentication
I don't think that I've done this (certainly not using client cert
based auth. at the present time). Not sure about other apache
se
