Greetings,
I have seen via google that this very problem was already discussed on several lists some months ago, but the archives report no solution.
I have a remote server with dovecot 1.0-0_12.beta8 on Centos 4.3. IMAP works just fine: I can read email from both Squirrelmail via web and Kmail.
Now I have created an ssl certificate on the server, and I'm trying to retrieve email via pop3s from my home PC (running suse, if this matters)
When I launch fetchmail here at home I get the error below. Is it caused by dovecot, or something else on the server, like some error I could have made when generating and copying certificates?
TIA, Marco
marco@polaris:~> fetchmail -vv fetchmail: 6.3.2 querying my.vps.fqdn.name (protocol POP3) at Tue 13 Jun 2006 05:22:50 PM CEST: +poll started fetchmail: Issuer Organization: SomeOrganization fetchmail: Issuer CommonName: localhost.localdomain fetchmail: Server CommonName: localhost.localdomain fetchmail: Server CommonName mismatch: localhost.localdomain != my.vps.fqdn.name fetchmail: my.vps.fqdn.name key fingerprint: 20:93:B4:D8:CB:75:AD:72:F6:00:A8:DC:CE:F2:53:6E fetchmail: my.vps.fqdn.name fingerprints do not match! 23942:error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify +failed:s3_clnt.c:894: fetchmail: SSL connection failed. fetchmail: socket error while fetching from remoteuser@my.vps.fqdn.name
On Tue, 13 Jun 2006, M. Fioretti wrote:
I have a remote server with dovecot 1.0-0_12.beta8 on Centos 4.3. IMAP works just fine: I can read email from both Squirrelmail via web and Kmail.
Now I have created an ssl certificate on the server, and I'm trying to retrieve email via pop3s from my home PC (running suse, if this matters)
When I launch fetchmail here at home I get the error below. Is it caused by dovecot, or something else on the server, like some error I could have made when generating and copying certificates?
marco@polaris:~> fetchmail -vv fetchmail: 6.3.2 querying my.vps.fqdn.name (protocol POP3) at Tue 13 Jun 2006 05:22:50 PM CEST: +poll started fetchmail: Issuer Organization: SomeOrganization fetchmail: Issuer CommonName: localhost.localdomain fetchmail: Server CommonName: localhost.localdomain fetchmail: Server CommonName mismatch: localhost.localdomain != my.vps.fqdn.name fetchmail: my.vps.fqdn.name key fingerprint: 20:93:B4:D8:CB:75:AD:72:F6:00:A8:DC:CE:F2:53:6E fetchmail: my.vps.fqdn.name fingerprints do not match! 23942:error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify +failed:s3_clnt.c:894: fetchmail: SSL connection failed. fetchmail: socket error while fetching from remoteuser@my.vps.fqdn.name
On your IMAP server, check out your certificate's thoughts about itself:
openssl x509 -noout -subject -in /path/to/cert.pem
I'm guessing that it'll report its common name (CN) as "localhost.domain." SSL clients typically want the remote cert's CN to match the hostname they're polling to avoid one server impersonating another.
You'll probably want to build a new cert, specifying the CN as the public hostname of your IMAP server, e.g.,
openssl req \ -x509 -nodes -days 365 \ -subj '/C=IT/L=Roma/CN=my.vps.fqdn.name' \ -newkey rsa:1024 -keyout mycert.pem -out mycert.pem
On Tue, Jun 13, 2006 09:43:46 AM -0700, Paul Heinlein (heinlein@madboa.com) wrote:
On your IMAP server, check out your certificate's thoughts about itself:
openssl x509 -noout -subject -in /path/to/cert.pem
I'm guessing that it'll report its common name (CN) as "localhost.domain."
I had realized the same thing a few minutes ago. :-( Silly me...
Right now I am rebuilding a new certificate on the server, byt I am setting my.vps.fqdn.name in openssl.cnf as CommonName_default and running the provided CA Perl Script. This would have the same effect as your command line option below, wouldn't it?
You'll probably want to build a new cert, specifying the CN as the public hostname of your IMAP server, e.g.,
openssl req \ -x509 -nodes -days 365 \ -subj '/C=IT/L=Roma/CN=my.vps.fqdn.name' \ -newkey rsa:1024 -keyout mycert.pem -out mycert.pem
Thanks, Marco
On Tue, 13 Jun 2006, M. Fioretti wrote:
Right now I am rebuilding a new certificate on the server, byt I am setting my.vps.fqdn.name in openssl.cnf as CommonName_default and running the provided CA Perl Script. This would have the same effect as your command line option below, wouldn't it?
You'll probably want to build a new cert, specifying the CN as the public hostname of your IMAP server, e.g.,
openssl req \ -x509 -nodes -days 365 \ -subj '/C=IT/L=Roma/CN=my.vps.fqdn.name' \ -newkey rsa:1024 -keyout mycert.pem -out mycert.pem
Yes, it should.
The nice thing about using the -subj option is that it allows you to skip all the interactive question/answer silliness.
On Tue, Jun 13, 2006 10:06:12 AM -0700, Paul Heinlein (heinlein@madboa.com) wrote:
On Tue, 13 Jun 2006, M. Fioretti wrote:
Right now I am rebuilding a new certificate on the server, byt I am setting my.vps.fqdn.name in openssl.cnf as CommonName_default and running the provided CA Perl Script. This would have the same effect as your command line option below, wouldn't it?
I have just done it but this time, after copying the cert and key on my home pc and running
openssl x509 -in mynewcertCert.pem -fingerprint -subject -issuer -serial -hash -noout
c_rehash .
I get:
Doing . WARNING: mynewcertPrivateKey.pem does not contain a certificate or CRL: skipping mynewcertCert.pem => 2764d17c.0
I had got no warning whatsoever the first time. What does this mean? Should I worry, or redo/change something?
Marco
-
M. Fioretti -
Paul Heinlein