On Saturday 02 October 2010 15:17:01 meino.cra...@gmx.de wrote: > Mick <michaelkintz...@gmail.com> [10-10-02 13:52]: > > On Saturday 02 October 2010 11:31:38 meino.cra...@gmx.de wrote: > > > Hi, > > > > > > fetchmail's log told me, that there is something wrong with the setup > > > of the certificats. > > > > > > In the log there is the following section > > > > > > fetchmail: Server certificate: > > > fetchmail: Issuer Organization: Thawte Consulting cc > > > fetchmail: Issuer CommonName: Thawte Premium Server CA > > > fetchmail: Subject CommonName: pop.gmx.net > > > > > > fetchmail: pop.gmx.net key fingerprint: > > > A6:57:BC:4A:97:AD:DB:99:00:E9:3A:B8:81:55:D7:B6 fetchmail: Server > > > certificate verification error: unable to get local issuer certificate > > > fetchmail: This means that the root signing certificate (issued for > > > /C=DE/ST=Bayern/L=Munich/O=GMX GmbH/CN=pop.gmx.net) is not in the > > > trusted CA certificate locations, or that c_rehash needs to be run on > > > the certificate directory. For details, please see the documentation > > > of --sslcertpath and --sslcertfile in the manual page. fetchmail: > > > Server > > > > > > certificate: > > > fetchmail: Issuer Organization: Thawte Consulting cc > > > fetchmail: Issuer CommonName: Thawte Premium Server CA > > > fetchmail: Subject CommonName: pop.gmx.net > > > fetchmail: Server certificate verification error: certificate not > > > > > > trusted fetchmail: Server certificate: > > > fetchmail: Issuer Organization: Thawte Consulting cc > > > fetchmail: Issuer CommonName: Thawte Premium Server CA > > > fetchmail: Subject CommonName: pop.gmx.net > > > fetchmail: Server certificate verification error: unable to verify > > > the > > > > > > first certificate fetchmail: Warning: the connection is insecure, > > > continuing anyways. (Better use --sslcertck!) > > > > > > > > > In beforehand I did the following: > > > > > > From the output of this command > > > > > > #> openssl s_client -connect pop.gmx.net:995 -showcerts > > > > > > I copied the section > > > > > > -----BEGIN CERTIFICATE----- > > > MIIDUzCCArygAwIBAgIQDNZUbIDJ5EM+DVSd5AzXOjANBgkqhkiG9w0BAQUFADCB > > > zjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJ > > > Q2FwZSBUb3duMR0wGwYDVQQKExRUaGF3dGUgQ29uc3VsdGluZyBjYzEoMCYGA1UE > > > CxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEhMB8GA1UEAxMYVGhh > > > d3RlIFByZW1pdW0gU2VydmVyIENBMSgwJgYJKoZIhvcNAQkBFhlwcmVtaXVtLXNl > > > cnZlckB0aGF3dGUuY29tMB4XDTEwMDQyMjAwMDAwMFoXDTEzMDUwOTIzNTk1OVow > > > WDELMAkGA1UEBhMCREUxDzANBgNVBAgTBkJheWVybjEPMA0GA1UEBxQGTXVuaWNo > > > MREwDwYDVQQKFAhHTVggR21iSDEUMBIGA1UEAxQLcG9wLmdteC5uZXQwgZ8wDQYJ > > > KoZIhvcNAQEBBQADgY0AMIGJAoGBAMu3VYZP3YqpNweeIp+zIYtAlYL9Nya5hq6j > > > k+ShUtukV1746nqJto70+4oNhCYJ33mMw+vS5fODjuggG+Z1xcL5YU8mUyG2E7fH > > > YkfNtHHMhRntN15ml7Kv3c52kmOI09r2psnlNPkkNx5shneON8jZfXYlqQq5Vq1l > > > Hz+jEjFrAgMBAAGjgaYwgaMwDAYDVR0TAQH/BAIwADBABgNVHR8EOTA3MDWgM6Ax > > > hi9odHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlU2VydmVyUHJlbWl1bUNBLmNy > > > bDAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwMgYIKwYBBQUHAQEEJjAk > > > MCIGCCsGAQUFBzABhhZodHRwOi8vb2NzcC50aGF3dGUuY29tMA0GCSqGSIb3DQEB > > > BQUAA4GBAF/BVQRh2QOAtH8491d2XIKqdRZNY4OUMh6qccb0xLGNTDx3E4iwoYHc > > > yi2axElQG+7VAEIbDftzfhVUttsPwLI0BM2Nvz6KkwnlrJmt9HuZOjyv9M6szCxX > > > jHqVXkTDtrvRzT3hHTLD63l4PAqAUDpR4Th4N23IyxpgVqmYZwoJ > > > -----END CERTIFICATE----- > > > > > > into a file "pop.gmx.net.pem" and copied ths file into > > > /etc/fetchmail/certs > > > > > > Than I downloaded the whole package of root certificates from here > > > https://www.verisign.com/support/thawte-roots.zip > > > unpacked it and copied each *.pem file into /etc/fetchmail/certs also. > > > I renamend the files to not to contain blanks with detox. > > > > > > > > > Then I run as root the command > > > > > > $> c_rehash /etc/fetchmail/certs > > > > > > I checked /etc/fetchmail/certs and found all files being symlinked to > > > something which looks like hash keys (?). > > > > > > c_hash does not submit any error message. > > > > > > After this I added below the poll section of my accounts > > > > > > $HOME/.fetchmailrc the following line: > > > sslcertpath /etc/fetchmail/certs > > > > > > Nonetheless fetchmail complains about local certifcates. > > > > > > What do I have to do to fix this ? > > > > > > Best regards and thank you for any help in advance! > > > mcc > > > > Sendmail and I think fetchmail (haven't used the latter yet) do a strict > > check of certs against a local store. The error above tells you to add > > to your .fetchmailrc the option of sslcertck. Did you do that? > > > > So your .fetchmailrc should show something like: > > > > user 'm...@gmx_whatever.com' with pass "123456" is 'mcc' here options ssl > > sslcertck sslcertpath '/etc/fetchmail/certs' > > > > If you have done the above and still does not work then the problem may > > be that the user you are running fetchmail as does not have read access > > to your /etc/fetchmail/certs. Change that to a ~/fetchmail/.certs and > > it should work. > > > > HTH. > > Hi Mick, > > thank you for your help. :) > > I currently have this line in my fetchtmailrc (the rest is commented out). > This had worked until the ssl/cert-showdown: > > poll pop.gmx.net protocol pop3 user "meino.cra...@gmx.de" password > "<this is the password>" mda "/usr/bin/procmail -d %T" > > In the inet and in your post I found a totally different syntax...so > it seems that I have lived behind the moon for a long time I didn't > get all the new syntax changes according to fetchmail ;) > > I chenged the above line to > poll pop.gmx.net protocol pop3 user "meino.cra...@gmx.de" password > "<this is the password>" mda "/usr/bin/procmail -d %T" options ssl > sslcertck sslcertpath '/etc/fetchmail/certs' > > which results with > fetchmail -v > in > fetchmail: 6.3.17 querying pop.gmx.net (protocol POP3) at Sat Oct 2 > 16:12:51 2010: poll started Trying to connect to > 212.227.17.185/995...connected. > fetchmail: Server certificate: > fetchmail: Issuer Organization: Thawte Consulting cc > fetchmail: Issuer CommonName: Thawte Premium Server CA > fetchmail: Subject CommonName: pop.gmx.net > fetchmail: pop.gmx.net key fingerprint: > A6:57:BC:4A:97:AD:DB:99:00:E9:3A:B8:81:55:D7:B6 fetchmail: Server > certificate verification error: unable to get local issuer certificate > fetchmail: This means that the root signing certificate (issued for > /C=DE/ST=Bayern/L=Munich/O=GMX GmbH/CN=pop.gmx.net) is not in the trusted > CA certificate locations, or that c_rehash needs to be run on the > certificate directory. For details, please see the documentation of > --sslcertpath and --sslcertfile in the manual page. > 17550:error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate > verify failed:s3_clnt.c:982: fetchmail: SSL connection failed. > fetchmail: socket error while fetching from > meino.cra...@gmx.de@pop.gmx.net fetchmail: 6.3.17 querying pop.gmx.net > (protocol POP3) at Sat Oct 2 16:12:51 2010: poll completed fetchmail: > Query status=2 (SOCKET) > fetchmail: normal termination, status 2 > > ls -l /etc/fetchmail/certs: > total 44 > lrwxrwxrwx 1 root root 30 Oct 2 12:10 09ca81a7.0 -> > Thawte_Personal_Premium_CA.pem lrwxrwxrwx 1 root root 26 Oct 2 12:10 > 2e4eed3c.0 -> thawte_Primary_Root_CA.pem lrwxrwxrwx 1 root root 28 Oct > 2 12:10 3a7f6b22.0 -> Thawte_Personal_Basic_CA.pem lrwxrwxrwx 1 root root > 50 Oct 2 12:10 415660c1.0 -> > Class_3_Public_Primary_Certification_Authority.pem lrwxrwxrwx 1 root root > 31 Oct 2 12:10 64d1f6f4.0 -> Thawte_Personal_Freemail_CA.pem lrwxrwxrwx > 1 root root 31 Oct 2 12:10 64d1f6f4.1 -> > thawte_Personal_Freemail_CA.pem lrwxrwxrwx 1 root root 20 Oct 2 12:10 > 6cc3c4c3.0 -> Thawte_Server_CA.pem lrwxrwxrwx 1 root root 28 Oct 2 > 12:10 98ec67f0.0 -> Thawte_Premium_Server_CA.pem lrwxrwxrwx 1 root root > 26 Oct 2 12:10 9e6afd31.0 -> Thawte_Timestamping_CA.pem -rw-r--r-- 1 root > root 833 Oct 2 12:06 Class_3_Public_Primary_Certification_Authority.pem > -rw-r--r-- 1 root root 1167 Oct 2 12:06 Thawte_Personal_Basic_CA.pem > -rw-r--r-- 1 root root 1183 Oct 2 12:06 Thawte_Personal_Freemail_CA.pem > -rw-r--r-- 1 root root 1175 Oct 2 12:06 Thawte_Personal_Premium_CA.pem > -rw-r--r-- 1 root root 1175 Oct 2 12:06 Thawte_Premium_Server_CA.pem > -rw-r--r-- 1 root root 1146 Oct 2 12:06 Thawte_Server_CA.pem > -rw-r--r-- 1 root root 992 Oct 2 12:06 Thawte_Timestamping_CA.pem > lrwxrwxrwx 1 root root 33 Oct 2 12:10 c089bbbd.0 -> > thawte_Primary_Root_CA-G2_ECC.pem lrwxrwxrwx 1 root root 15 Oct 2 12:10 > ec4e2774.0 -> pop.gmx.net.pem -rw-r--r-- 1 root root 1213 Oct 2 12:10 > pop.gmx.net.pem > -rw-r--r-- 1 root root 1164 Oct 2 12:06 > thawte_Personal_Freemail_CA.pem -rw-r--r-- 1 root root 939 Oct 2 12:06 > thawte_Primary_Root_CA-G2_ECC.pem -rw-r--r-- 1 root root 1493 Oct 2 12:06 > thawte_Primary_Root_CA.pem > > everything is world readable... > > Finally I did a fetchmail --version which gave me: > This is fetchmail release 6.3.17+RPA+NTLM+SDPS+SSL+NLS. > > Copyright (C) 2002, 2003 Eric S. Raymond > Copyright (C) 2004 Matthias Andree, Eric S. Raymond, > Robert M. Funk, Graham Wilson > Copyright (C) 2005 - 2006, 2010 Sunil Shetye > Copyright (C) 2005 - 2010 Matthias Andree > Fetchmail comes with ABSOLUTELY NO WARRANTY. This is free software, and > you are welcome to redistribute it under certain conditions. For details, > please see the file COPYING in the source or documentation directory. > > Fallback MDA: (none) > Linux solfire 2.6.35.7 #2 SMP PREEMPT Thu Sep 30 14:29:29 CEST 2010 > x86_64 AMD Phenom(tm) II X6 1090T Processor AuthenticAMD GNU/Linux Taking > options from command line and /home/mccramer/.fetchmailrc Idfile is > /home/mccramer/.fetchids > Fetchmail will forward misaddressed multidrop messages to mccramer. > Options for retrieving from meino.cra...@gmx.de@pop.gmx.net: > True name of server is pop.gmx.net. > Protocol is POP3. > All available authentication methods will be tried. > SSL encrypted sessions enabled. > SSL server certificate checking enabled. > SSL trusted certificate directory: /etc/fetchmail/certs > Server nonresponse timeout is 300 seconds (default). > Default mailbox selected. > Only new messages will be retrieved (--all off). > Fetched messages will not be kept on the server (--keep off). > Old messages will not be flushed before message retrieval (--flush > off). Oversized messages will not be flushed before message retrieval > (--limitflush off). Rewrite of server-local addresses is enabled > (--norewrite off). Carriage-return stripping is enabled (stripcr on). > Carriage-return forcing is disabled (forcecr off). > Interpretation of Content-Transfer-Encoding is enabled (pass8bits > off). MIME decoding is disabled (mimedecode off). > Idle after poll is disabled (idle off). > Nonempty Status lines will be kept (dropstatus off) > Delivered-To lines will be kept (dropdelivered off) > Fetch message size limit is 100 (--fetchsizelimit 100). > Do binary search of UIDs during 3 out of 4 polls (--fastuidl 4). > Messages will be delivered with "/usr/bin/procmail -d %T". > Single-drop mode: 1 local name recognized. > No UIDs saved from this host. > > I have no clue, whether the certs are not accepted... > > What did I wrong? > > Best regards > mcc
Hmm ... can't see anything amiss, but as I said I have not used fetchmail. Perhaps a more seasoned fetchmail gentooist will chime in here. Until then three more things to check, or do: Have you installed *all* the CA root certs? (There may be some intermediate certs that are required - you will need the complete chain of the root certs saved in your /etc/fetchmail/certs and then run c_rehash. Check the atime of the contents of your /etc/fetchmail/certs to make sure that the c_rehash worked). Also add: sslfingerprint A6:57:BC:4A:97:AD:DB:99:00:E9:3A:B8:81:55:D7:B6 to your fetchtmailrc. Finally, just in case the access rights are somewhat incorrect, copy your /etc/fetchmail/certs to ~/.fetchmail/.certs and run c_rehash for that directory. HTH. -- Regards, Mick
signature.asc
Description: This is a digitally signed message part.
