hostingprovider heeft raar certificaat

[MrScratch]

Ik heb mijn website bij een hostingprovider staan met daarbij ook de mailserver. Ik haal met fetchmail mijn mail op van de website. Nu krijg ik sinds een tijdje de volgende melding:

fetchmail: Server CommonName mismatch: www.snakeoil.dom != <mailserver domein>
fetchmail: Server certificate verification error: unable to get local issuer certificate
fetchmail: Server certificate verification error: certificate not trusted
fetchmail: Server certificate verification error: unable to verify the first certificate

Het lijkt erop dat er geen goed certificaat is geinstalleerd bij de hosting provider, maar echt veel begrijp ik er niet van. Wat moet ik hier nu aan doen? Is het tijd om een andere hostingprovider te zoeken?

[smesjz]

Je zou je provider kunnen vragen of ze i.p.v. self-signed certificaat (Snakeoil is waar openssl zelf mee komt als je een eigen SSL certificaat laat generen afaik) een certificaat nemen dat geissued is door een third-party zoals VeriSign/Thawte etc. Dan ben je van die waarschuwen af.

Het is niet professioneel van een provider om het op deze manier te doen, maar ook geen reden om meteen panisch te reageren en weg te gaan. Het siert je als je eerst contact met hen op neemt

[MrScratch]

Ik heb reeds gemeld bij ze dat ik deze foutmeldingen kreeg, maar het advies was om dan maar geen ssl te gebruiken. Dan gaan mijn wachtwoorden onbeschermd het internet over en dat lijkt me ook niet echt fijn.

Op zich werkt het ophalen van email wel, maar fetchmail maakt een email aan waarin deze fout wordt gemeld. Omdat de email elke minuut wordt opgehaald, krijg ik dus elke minuut een mail met deze melding en dat telt toch aardig op. Daar wil ik wel vanaf minimaal.

[Snake]

Importeer dat certificaat in je thrusted root. Nadeel is dan wel dat je ieder certificaat wat met dat certificaat getekend is vertrouwd.

Kan je niet een exception voor dat certificaat alleen toevoegen?

[smesjz]

Simple google werk levert dit op:

http://www.dns.net/andras/computer/ssl-fetchmail.html

Heb je dit al geprobeerd?

[MrScratch]

Ik had al flink wat gegoogled, maar daar was ik nog niet uitgekomen. Ik heb nu een certificate in de hostingprovider.pem file zitten en de meldingen veranderen zodanig dat ik nu een error krijg ipv de warning.

fetchmail: Server CommonName mismatch: www.snakeoil.dom != <mailserver-adres>
fetchmail: Server certificate verification error: unable to get local issuer certificate
5262:error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed:s3_clnt.c:983:
fetchmail: SSL connection failed.
fetchmail: socket error while fetching from <emailadres@mailserver-adres>
fetchmail: Query status=2 (SOCKET)

[Kees]

Leuk dat ze een self signed certificaat gebruiken, maar op zijn minst kunnen ze dan wel gewoon de juiste mailserver adres als cn instellen ipv gewoon op enter te rammen en alle default waardes over te nemen (snakeoil.dom wordt heel veel als voorbeeld gebruikt).

[MrScratch]

Kees schreef op maandag 01 maart 2010 @ 12:23:
Leuk dat ze een self signed certificaat gebruiken, maar op zijn minst kunnen ze dan wel gewoon de juiste mailserver adres als cn instellen ipv gewoon op enter te rammen en alle default waardes over te nemen (snakeoil.dom wordt heel veel als voorbeeld gebruikt).

Dus als ik het goed begrijp, zou de procedure moeten zijn dat ik aan de hostingprovider verzoek om een self-signed certificaat te genereren met de goede cn erin. Vervolgens kan ik dat certificaat importeren in mijn config en dan zouden de warnings weg moeten zijn.

Kunnen of willen ze dat niet doen, dan wordt het tijd voor een nieuwe hostingprovider?

[swbr]

MrScratch schreef op maandag 01 maart 2010 @ 12:29:
[...]
Kunnen of willen ze dat niet doen, dan wordt het tijd voor een nieuwe hostingprovider?

Als ze je aanraden om 'dan maar geen ssl te gebruiken' zou het voor mij sowieso tijd voor een andere provider worden eerlijk gezegd.

[MrScratch]

Ik denk dat ik ze verkeerd gequote heb. Ze geven aan dat ze geen certificates ondersteunen bij het mailophalen, niet dat je niet via ssl kunt ophalen.

Vervelende is echter dat ik fetchmail niet zover leek te krijgen om niet naar dat certificaat te kijken. Ik heb nu echter uitgevogeld dat als ik protocol IMAP gebruik en het commando "sslproto ssl23" toevoeg aan de opdrachtregel in .fetchmailrc dat er dan geen TLS wordt gebruikt en daardoor ook geen foutmeldingen meer krijg.

Enige is dat ik nu niet zeker weet of ik de mail nog op een veilige manier ophaal of niet.

[swbr]

MrScratch schreef op dinsdag 02 maart 2010 @ 19:53:
Enige is dat ik nu niet zeker weet of ik de mail nog op een veilige manier ophaal of niet.

Dan installeer je wireshark en ga je je netwerkverkeer sniffen op het moment dat je mail ophaalt. Dan zie je snel genoeg of je pakketjes encrypted over het netwerk gaan of niet.

[MrScratch]

Antaresje schreef op dinsdag 02 maart 2010 @ 21:57:
[...]


Dan installeer je wireshark en ga je je netwerkverkeer sniffen op het moment dat je mail ophaalt. Dan zie je snel genoeg of je pakketjes encrypted over het netwerk gaan of niet.

Dat is een goede tip, dat kende ik nog niet.

Ik heb inmiddels al gezien dat het niet secure gaat. Als ik fetchmail op verbose zet, zie ik precies wat hij uitspookt en de mail wordt van poort 143 gehaald en dat is niet encrypted. SSL enabled imap zit op poort 993. Helaas, dus.

[Foamy]

MrScratch schreef op dinsdag 02 maart 2010 @ 22:09:
[...]

Dat is een goede tip, dat kende ik nog niet.

Ik heb inmiddels al gezien dat het niet secure gaat. Als ik fetchmail op verbose zet, zie ik precies wat hij uitspookt en de mail wordt van poort 143 gehaald en dat is niet encrypted. SSL enabled imap zit op poort 993. Helaas, dus.

Alleen naar poortnummers kijken zegt niets over wat voor data er over het lijntje gaat. Mijn provider bied zijn IMAP en SMTP diensten op de standaardpoorten aan (143 en 25) en dat gaat toch echt wel encrypted...