* On 2003.04.02, in <[EMAIL PROTECTED]>,
* "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> On Mon, 24 Mar 2003, Roland Schmid wrote:
>
> > my OS is Redhat 7.3.
> > Does it matter which extension i use with the certificate (e.g.
> > certificate.crt or certificate.pem
> > Is it possible to compile qpopper a second time including your
> > mentioned workaround?
Crle on Solaris 8/9 is analogous to ldconfig on Red Hat. IIRC, there's
some sort of file you can add library paths to -- /etc/ldconfig.conf or
something like that.
Or you can recompile with the "-R /usr/local/whatever/it/was".
But it sounds like linkage is working, or it wouldn't work on port 110.
Do you have options in your popper.conf specifying the location of the
SSL certificates?
> What type of Verisign certificate should be used? Is it the same
> type of certificate that you'd use with apache?
The certificate file should be PEM format, with or without the leading
text material describing the X.509 structure. Qpopper will skip ahead to
the BEGIN CERTIFICATE part, which is what matters.
The key used to generate the cert can go in a separate file, or in the
same file. It must also be in PEM format.
The names of the files don't matter.
N.B. I've seen some troubles with Verisign's recently-issued
certificates. What it amounts to, as far as I can see -- there was
nothing in Google about this particular problem, from a server
perspective, when I ran across it -- is that they changed their CA's
signing certificate. You now need to import their "interim" CA cert
into your client's CA list, or, failing that, to include it in the
server-side file with the server's certificate so that it can be
provided to the client alongside your server cert. Just concatenate
the certs for the entire trust path into the file containing the
PEM-formatted server certificate.
(This trick works with uw-imap, at any rate. I haven't tried with
popper, because our Verisign cert for popper is older, and is signed
by their old CA cert, which is in all our clients' CA caches.)
In my estimation, Verisign lost whatever credibility they had with this
maneuver. I imagine it was necessary, though -- so to look at it another
way, this switch revealed that the value they sell is in fact very
little. Verisign's sole value to us was that they were in our clients'
CA caches already, and our local CA was not. Now that Verisign isn't
either, why pay them $100/year for each SSL service we operate? I'm sure
this is just a temporary situation with Verisign, and when my clients
upgrade Netscape to whatever version Verisign paid $350,000 (or whatever
the price tag is) to get their new cert into, the problem will go away.
But it'll come back eventually -- if not for Verisign, then for some
other CA. Meanwhile, I have a problem situation, and the only scalable
solution is to deliver my clients a CA cert with each SSL transaction.
But I can deliver my clients my own CA cert as easily as I can deliver
them Verisign's, and solve the problem forever.
--
-D. [EMAIL PROTECTED] NSIT University of Chicago
"The whole thrust of the text adventure was one picture was worth
a thousand words and we would rather give you the thousand words."
- Dave Lebling, Implementor
