SMTP SSL over poort 443: server weigert.

[JJ Le Funk]

Ik wil graag mijn email-POP-account gebruik laten maken van een SSL-certificaat dat ik heb geïnstalleerd op een website (site draait als VHost via Apache); laten we zeggen www.testdomein.nl

Dus ik zet 't SMTP-adres van het nieuwe mailaccount (bijv. [e-mail]) op het ip-adres van www.testdomein.nl en de SSL-poort op 443 om te zien of het juiste certificaat wordt opgehaald. Dat slaagt (natuurlijk wel met principal name error, maar is op dit punt nog niet relevant).

Vervolgens verstuur ik een mailtje. Dit mislukt: server time-out.
De server weigert SMTP-verkeer over 443+SSL.

Eerst dacht ik dat ik poort 443 moest toevoegen aan de EXIM config file. Maar hielp niet.
Toen firewall gecheckt: deze kan wel emailverkeer op alternatieve poorten blokkeren maar deze functie staat niet aan (ik gebruik DirectAdmin CSF).

Is de poort misschien in gebruik door SSH? Ik kan met Putty alleen over poort 22 SSH'en, dus nee.

Op de server staat nog, buiten de VHosts om, een self signed SSL. Deze wordt telkens aangeboden door Outlook als ik via de standaard SSL poorten probeer te mailen. Komt dit doordat EXIM dit forceert?

Mijn vraag is dus: hoe maak ik poort 443 vrij voor smtp? Moet ik dan het self signed certificaat-verwijzing verwijderen uit de httpd conf waarna smtp wel de SSL uit de Vhost plukt?


UPDATE: stukje achtergrond bij de FP:
"
Aanleiding: ik wil dat elke klant mail ontvangt dat is encrypted dmv. het eigen, domeinspecifieke SSL-certificaat.
En niet, zoals nu, via het self signed certificaat dat op de server staat.
Zodat de klant zelf kan verifiëren dat emailverkeer niet alleen versleuteld is maar ook uniek versleuteld en via partijen die de klant kan nagaan en zelf bepalen of hij deze vertrouwd.
En zo nog wat redenen: minder kans op spamlisting wanneer 1 klant zich 'misdraagt' qua emailgebruik.
"

Beste antwoord tot dusver:
CyBeR in "SMTP SSL over poort 443: server weigert."

[ Voor 22% gewijzigd door JJ Le Funk op 05-11-2013 17:40 . Reden: FP geüpdate voor leesbaarheid ]

[Ultraman]

SMTP over poort 443 is ongebruikelijk, die is voor HTTPS bestemd.

Als je mail wilt versturen naar je eigen SMTP server wordt meestal gebruik gemaakt van de "SMTP Submission" poort, dat is poort 587. Die configureer je dan om enkel mail te accepteren door geauthenticeerde gebruikers (dus met account). Gebruikelijk is het dat voor encryptie STARTTLS gebruikt wordt in dit geval.
Een wat oudere variant is SMTP+SSL, daarvoor is poort 465 de standaard. Minder gebruikelijk hedendaags, maar kom je nog steeds tegen.

Het is mij echter wat onduidelijk wat je precies probeert klaar te spelen.
Heb je een SMTP server draaien achter www.testdomein.nl en wil je met die SMTP server mail versturen? Luistert de SMTP server naar de juiste poorten? Kijk niet enkel naar de configuratie maar controleer of dit ook daadwerkelijk het geval is.
Luistert Apache (of een andere webserver) niet al naar poort 443 voor HTTPS verbindingen? Zoals bijv voor een webmail client.

Of ben je bezig vanaf een ander account een email te versturen naar [e-mail] ?
In dat laatste geval kun je je SMTP server het beste op poort 25 laten luisteren om mail te accepteren (of eventueel 465 als je daar ook mail op accepteert). Ook mail over poort 25 is trouwens steeds vaker encrypted middels STARTTLS, een grote partij die dit doet is o.a. GMail. Als je het op poort 25 optioneel aanbied zie je het steeds vaker gebruikt worden (ik iig wel).

[ Voor 3% gewijzigd door Ultraman op 05-11-2013 13:50 ]

[pablo_p]

Volgens mij haal je een aantal dingen door mekaar die je los moet zien:
SSL certificaat - poort 443 - POP - SMTP - website

Om de concepten even scherper neer te zetten:
- een signed SSL certicaat op een server installeren maakt het mogelijk voor clients om bij een connectie de server te authentiseren
- SMTP is een protocol dat gebruikt wordt om mail te versturen, niet om mail op te halen. Zonder encryptie is de standaardpoort voor SMTP poort 25
- poort 443 is de standaard poort voor het gebruik van HTTP over SSL/TLS, waarvoor de afkorting https wordt gebruikt, maar voor https kan een willekeurige pport gebruikt worden
- een website maakt gebruik van het HTTP protocol. Zonder encryptie wordt standaard poort 80 gebruikt, met encryptie 443. Een insecure of secure HTTTP server kan op een willekeurige poort luisteren
- Voor SMTP secure (SMTPs) is de IANA poort 587, maar vaak wordt 465 gebruikt.

Wat je nu probeert is SMTPS te communiceren met een web (HTTP) server en dat werkt niet. Ik denk dat het handiger is om poort 443 gereserveerd te houden voor HTTPS en je SMTPS server op poort 465 of 587 te draaien met certificaat.

--- inhoud is overlappend met reactie van Ultraman doordat we op hetzelfde moment aan het reageren waren ---

[ Voor 4% gewijzigd door pablo_p op 05-11-2013 13:42 ]

[Ultraman]

Helder verhaal, goede uitleg, kleine nuance:

pablo_p schreef op dinsdag 05 november 2013 @ 13:41:- SMTP is een protocol dat gebruikt wordt om mail te versturen, niet om mail op te halen.

Er wordt ook mail op ontvangen, door de server weliswaar.
De SMTP server geeft het vervolgens door aan een Mail Delivery Agent welke het in de juiste Inbox stopt.

De gebruiker heeft daar verder niks mee te maken, die babbelt met een POP en/of IMAP server, welke de mail voor de gebruiker uit dien mail directory leest.

[JJ Le Funk]

Ultraman schreef op dinsdag 05 november 2013 @ 13:40:
SMTP over poort 443 is ongebruikelijk, die is voor HTTPS bestemd.

Als je mail wilt versturen naar je eigen SMTP server wordt meestal gebruik gemaakt van de "SMTP Submission" poort, dat is poort 587. Die configureer je dan om enkel mail te accepteren door geauthenticeerde gebruikers (dus met account). Gebruikelijk is het dat voor encryptie STARTTLS gebruikt wordt in dit geval.
Een wat oudere variant is SMTP+SSL, daarvoor is poort 465 de standaard. Minder gebruikelijk hedendaags, maar kom je nog steeds tegen.

ik wil juist alle standaard poorten voor email mijden. Anders ziet de EXIM het als mailverkeer en serveert ie het server certificaat ipv. domeincertificaat.

Het is mij echter wat onduidelijk wat je precies probeert klaar te spelen.

Ik wil elke vhost (afzonderlijk domein+IP) het website SSL-certificaat laten hergebruiken voor email.

Heb je een SMTP server draaien achter www.testdomein.nl en wil je met die SMTP server mail versturen?

nee, de mail service draait op server level (geen VHOST). Deze is te benaderen via een Shared IP.

Luistert de SMTP server naar de juiste poorten? Kijk niet enkel naar de configuratie maar controleer of dit ook daadwerkelijk het geval is.

Email werkt en is al een tijd in gebruik, echter op basis van het self signed server certificate (handmatig toevoegen per software client).

Luistert Apache (of een andere webserver) niet al naar poort 443 voor HTTPS verbindingen? Zoals bijv voor een webmail client.

Alleen SSH geprobeerd.
Weet niet goed hoe ik een individuele poort kan testen of deze open staat/vrij is? Heeft DirectAdmin 443 gereserveerd zonder deze te gebruiken?

Of ben je bezig vanaf een ander account een email te versturen naar [e-mail] ?

nee dat niet

pablo_p schreef op dinsdag 05 november 2013 @ 13:41:
[uitleg]

dankje voor de uitgebreide uitleg. Dit komt aardig overeen met mijn beeld van de default port layout.
Afwijken van een standaard poort is voor beveiliging vaak positief: security by obscurity

[Jazzy]

Ik begrijp het niet zo goed. Exim is dus je mailserver, wat heb je gedaan om deze op een niet standaard poort te laten draaien? Daar heb je dan ook geconfigureerd welk certificaat er gebruikt moet worden om de SMTP verbinding te versleutelen.

Ik neem aan dat je TLS wilt doen, zet deze eerst nog even uit. Dan kun je met telnet op je niet-standaard poort connecten en controleren of je een SMTP-banner krijgt. Zet vervolgens TLS aan en kijk of je een TLS verbinding kunt opbouwen.

Misschien begrijp ik je niet goed maar ik heb niet helemaal precies door wat je probeert te bereiken. Dat je uitgerekend poort 443 kiest om je mailserver op te laten luisteren is al helemaal vragen om problemen...

[ Voor 8% gewijzigd door Jazzy op 05-11-2013 14:08 ]

[JJ Le Funk]

Jazzy schreef op dinsdag 05 november 2013 @ 14:07:
Ik begrijp het niet zo goed. Exim is dus je mailserver, wat heb je gedaan om deze op een niet standaard poort te laten draaien? Daar heb je dan ook geconfigureerd welk certificaat er gebruikt moet worden om de SMTP verbinding te versleutelen.

die gebruikt inderdaad een zelf gebakken certificaat. Maar draaide al zo toen ik de server in gebruik nam. Omdat er al klanten mee werken kan ik dat niet zomaar wijzigen. Overigens wel geprobeerd een 2e -trusted- certificaat eraan toe te voegen maar dat resulteerde in een Apache crash.
Liever omzeil ik Exim dus.

Ik neem aan dat je TLS wilt doen, zet deze eerst nog even uit. Dan kun je met telnet op je niet-standaard poort connecten en controleren of je een SMTP-banner krijgt. Zet vervolgens TLS aan en kijk of je een TLS verbinding kunt opbouwen.

lijkt me dat TLS al aan staat. Deze gebruik ik namelijk al over poort 25.
Maar heb ik TLS nodig dan? Kan toch ook kiezen voor SSL?

Misschien begrijp ik je niet goed maar ik heb niet helemaal precies door wat je probeert te bereiken. Dat je uitgerekend poort 443 kiest om je mailserver op te laten luisteren is al helemaal vragen om problemen...

443 is eerste waar ik aan dacht omdat deze altijd geaccepteerd zal worden. Ik weet namelijk niet hoe de netwerk infra eruit ziet bij een klant.

Bestaat er ook een mixed mode waarin je SMTP en HTTP-verkeer door dezelfde poort trekt?
Vraag me af of ik HTTPS webverkeer niet onmogelijk maak als ik de poort ga gebruiken voor SMTP...

[ Voor 6% gewijzigd door JJ Le Funk op 05-11-2013 14:21 ]

[nautaonline]

Je kan in je exim.conf file ook aangeven dat er een ander certificaat gebruikt moet worden ipv de self signed..

Ik weet dat het kan, maar hoe het ook alweer zat.. dat is lang geleden.. Ooit eens bij een vorige werkgever de boel geconfigureerd...

[JJ Le Funk]

nautaonline schreef op dinsdag 05 november 2013 @ 14:20:
Je kan in je exim.conf file ook aangeven dat er een ander certificaat gebruikt moet worden ipv de self signed..

Ik weet dat het kan, maar hoe het ook alweer zat.. dat is lang geleden.. Ooit eens bij een vorige werkgever de boel geconfigureerd...

Dan nog moet ik meerdere SSL-certificaten erin kwijt kunnen en ik weet inmiddels uit eigen ervaring dat keys en certs onder elkaar plakken in de files die EXIM daarvoor gebruikt, een negatief effect heeft op de uptime

[Jazzy]

SMTP over SSL is een wezenlijk ander protocol dat HTTP over SSL, misschien zit daar je denkfout. Bovendien kan er maar één applicatie luisteren op een IP-adres een poortnummer, dat is dus ofwel Apache die HTTP kan aannemen ofwel Exim die SMTP verstaat.

Dus als je wilt dat Exim mail accepteert op poort 443 dan moet je deze hiervoor configureren en bovendien zorgen dat er geen andere applicatie op die poort luistert, anders kan Exim de poort niet claimen.

[ Voor 29% gewijzigd door Jazzy op 05-11-2013 14:26 ]

[JJ Le Funk]

Jazzy schreef op dinsdag 05 november 2013 @ 14:25:
SMTP over SSL is een wezenlijk ander protocol dat HTTP over SSL, misschien zit daar je denkfout. Bovendien kan er maar één applicatie luisteren op een IP-adres een poortnummer, dat is dus ofwel Apache die HTTP kan aannemen ofwel Exim die SMTP verstaat.

De protocollen zijn verschillend. Maar de tunnel is daarentegen gelijk. En daar gaat het me om. Maar dan wel die op poort 443.

Dus als je wilt dat Exim mail accepteert op poort 443 dan moet je deze hiervoor configureren en bovendien zorgen dat er geen andere applicatie op die poort luistert, anders kan Exim de poort niet claimen.

Liever geen SSL via Exim aangezien het mij niet lukt daar meerdere Vhost specifieke SSL's in te hangen.

Ik moet me verdiepen in telnet denk ik om 443 vrij te spelen?

[Jazzy]

MrJayMan schreef op dinsdag 05 november 2013 @ 14:39:
[...]

De protocollen zijn verschillend. Maar de tunnel is daarentegen gelijk. En daar gaat het me om. Maar dan wel die op poort 443.

Het gaat wel degelijk om het protocol, je kunt toch geen SMTP praten met Apache? Of het nu versleuteld is of niet, je zult toch echt je mailserver op die poort moeten laten luisteren. Er is niet zoiets als een 'standaard SSL poort', SSL is slechts een methode om de sessie te versleutelen.

Laat ik de vraag eens aan jou stellen: welk stuk software op je server zou de via SMTP aangeleverde mail moeten aannemen? En heb je dat stuk software hiervoor geconfigureerd?

[ Voor 14% gewijzigd door Jazzy op 05-11-2013 14:49 ]

[JJ Le Funk]

Jazzy schreef op dinsdag 05 november 2013 @ 14:46:
[...]

Het gaat wel degelijk om het protocol, je kunt toch geen SMTP praten met Apache? Of het nu versleuteld is of niet, je zult toch echt je mailserver op die poort moeten laten luisteren. Er is niet zoiets als een 'standaard SSL poort', SSL is slechts een methode om de sessie te versleutelen.

ik moet inderdaad Apache configureren dat deze niet luistert naar HTTP(S)-verkeer op poort 443. Dan is SSL verder niet meer mogelijk voor een domein. Maar daar valt mee te leven...

Vraag me wel af of ik niet een kwetsbaarheid creëer op deze manier. Stel: iemand pompt iets anders dan mail-verkeer naar de server@443. Dan crasht Exim...
Hm. That defies it all

[ Voor 13% gewijzigd door JJ Le Funk op 05-11-2013 14:56 ]

[Jazzy]

En vervolgens dus Exim configureren om juist wel op deze poort te luisteren.

Maar toch nog even terug... Je server luistert al op poort 25, heeft dus een hostnaam en je hebt blijkbaar een SSL certificaat met juiste subject want TLS op poort 25 werkt al.

Wat was ook alweer de reden dat je hiernaast ook nog op een andere poort mail wilt kunnen accepteren?

MrJayMan schreef op dinsdag 05 november 2013 @ 14:48:
Vraag me wel af of ik niet een kwetsbaarheid creëer op deze manier. Stel: iemand pompt iets anders dan mail-verkeer naar de server@443. Dan crasht Exim...
Hm. That defies it all

Denk je echt dat Exim zo kwetsbaar is? Connect dan eens met Telnet op poort 25 van je mailserver en type eens een HTML request in (GET...). Je krijgt een keurige SMTP foutcode omdat Exim alleen SMTP spreekt.

Maar door je aanpak, de (net niet helemaal juiste) termen die je gebruikt en het feit dat je bovenstaande vraag stelt maak ik me wel een beetje zorgen of je helemaal begrijpt wat je aan het doen bent. Waarom draai je het niet eens om en vertel je (functioneel) wat je probleem is en wat je zou willen bereiken? Dan kunnen wij misschien een beter advies geven.

[ Voor 58% gewijzigd door Jazzy op 05-11-2013 15:06 ]

[JJ Le Funk]

Jazzy schreef op dinsdag 05 november 2013 @ 14:56:
En vervolgens dus Exim configureren om juist wel op deze poort te luisteren.

Maar toch nog even terug... Je server luistert al op poort 25, heeft dus een hostnaam en je hebt blijkbaar een SSL certificaat met juiste subject want TLS op poort 25 werkt al.

werkt, maar met self signed SSL op een shared IP. Is daardoor niet trusted voor klanten en niet bruikbaar voor mijn dienstverlening.

Wat was ook alweer de reden dat je hiernaast ook nog op een andere poort mail wilt kunnen accepteren?

Ik wil dat elke klant mail ontvangt en verstuurt dat is versleuteld met het eigen domeinspecifieke SSL-certificaat.

Denk je echt dat Exim zo kwetsbaar is? Connect dan eens met Telnet op poort 25 van je mailserver en type eens een HTML request in (GET...). Je krijgt een keurige SMTP foutcode omdat Exim alleen SMTP spreekt.

als ik 443 open zet dan is het wachten tot EXIM vast loopt en zelfs de server. Er is webverkeer op die poort.

[...] Waarom draai je het niet eens om en vertel je (functioneel) wat je probleem is en wat je zou willen bereiken? Dan kunnen wij misschien een beter advies geven.

Ik wil dat elke klant mail ontvangt dat is encrypted dmv. het eigen, domeinspecifieke SSL-certificaat.
En niet, zoals nu, via het self signed certificaat dat op de server staat.
Zodat de klant zelf kan verifiëren dat emailverkeer niet alleen versleuteld is maar ook uniek versleuteld en via partijen die de klant kan nagaan en zelf bepalen of hij deze vertrouwd.
En zo nog wat redenen: minder kans op spamlisting wanneer 1 klant zich 'misdraagt' qua emailgebruik.

Ik ga me even verdiepen in Dovecot; misschien kan ik dat gebruiken voor certifcaatbeheer voor emailgebruik per Vhost ??

[ Voor 12% gewijzigd door JJ Le Funk op 05-11-2013 16:10 . Reden: dovecot? ]

[pablo_p]

Begrijp ik goed dat je meerdere certificaten aan een listener wilt hangen? Besef wel dat je per combinatie (IP adres)+(TCP poort) maar 1 certificaat kan koppelen. Het virtual hosting van HTTP werkt niet, omdat er eerst SSL gecommuniceerd wordt (en geauthenticeerd) voordat je met het getunnelde protocol communicatie hebt.

Meerdere SSL sites achter 1 IP-port combinatie kan alleen met wildcard certificaten of multi-domein certificaten. Multi-domeinen certificaten hebben weer browser platform/versie afhankelijkheden. Wildcard certificaten werken alleen als zoiets als klantA.jeeigendomein.nl en klantB.jeeigendomein.nl gebruikt. Een wildcard certificaat voor *.com of *.nl hoor je niet te kunnen krijgen bij een gerenommeerde certificatenboer. Dan moet je diginotar hacken ofzo
Opties zijn dan verschillende poorten te gebruiken (af te raden) of 1 IP adres per domein en dezelfde poort.

[ Voor 7% gewijzigd door pablo_p op 05-11-2013 15:57 . Reden: Toevoegen optie meerdere IP adressen/poorten ]

[Jazzy]

pablo_p schreef op dinsdag 05 november 2013 @ 15:55:
Begrijp ik goed dat je meerdere certificaten aan een listener wilt hangen? Besef wel dat je per combinatie (IP adres)+(TCP poort) maar 1 certificaat kan koppelen. Het virtual hosting van HTTP werkt niet, omdat er eerst SSL gecommuniceerd wordt (en geauthenticeerd) voordat je met het getunnelde protocol communicatie hebt.

Meerdere SSL sites achter 1 IP-port combinatie kan alleen met wildcard certificaten of multi-domein certificaten. Multi-domeinen certificaten hebben weer browser platform/versie afhankelijkheden. Wildcard certificaten werken alleen voor je als klantA.jeeigendomein.nl en klantB.jeeigendomein.nl gebruikt. Een wildcard certificaat voor *.com of *.nl hoor je niet te kunnen krijgen bij een gerenommeerde certificatenboer. Dan moet je diginotar hacken ofzo

Sterker nog, het gaat om een mailserver en niet om een webserver. Hierbij geldt hetzelfde, namelijk dat de server (combinatie IP-adres en poortnummer) maar op één naam kan reageren.

[pablo_p]

Ik heb mijn formulering wat voorzichtig gekozen omdat ik SMTP niet heel goed ken. Ik kan we wel voorstellen dat het mogelijk is om in te loggen met username@domainname als inlognaam, waarmee je domeinspecifieke instellingen kan gaan gebruiken (bv maximale mailsize etc, andere spam filtering).

Jazzy schreef op dinsdag 05 november 2013 @ 15:57:
[...]
Sterker nog, het gaat om een mailserver en niet om een webserver. Hierbij geldt hetzelfde, namelijk dat de server (combinatie IP-adres en poortnummer) maar op één naam kan reageren.

Ik zou het andersom formuleren: een ip-port combinatie kan maar met 1 certificaat reageren.

Je kan 100.000 domeinnamen naar 1 IP adres laten verwijzen en de server reageert dan altijd, alleen altijd met hetzelfde certificaat

[CyBeR]

MrJayMan schreef op dinsdag 05 november 2013 @ 15:44:
[...]

Ik wil dat elke klant mail ontvangt en verstuurt dat is versleuteld met het eigen domeinspecifieke SSL-certificaat.

Dan heb je per klant een IP-adres nodig waar je Exim op poort 465 laat luisteren. (Samen met 25 en 587 voor TLS met STARTTLS.)

als ik 443 open zet dan is het wachten tot EXIM vast loopt en zelfs de server. Er is webverkeer op die poort.

Exim kan daar prima tegen maar je doet iets raars zonder daar een goede reden voor te hebben. SMTP praat je op 25, 465 (legacy ssl voor outlook) en 587.

Ik ga me even verdiepen in Dovecot; misschien kan ik dat gebruiken voor certifcaatbeheer voor emailgebruik per Vhost ??

Dovecot is een MUA; doet niks met smtp.

[JJ Le Funk]

Ter verduidelijking:
[list]
• Elke klant heeft eigen FQDN + vast IP + SSL.
• De Linux-gebaseerde server is zowel web als mail server.

CyBeR schreef op dinsdag 05 november 2013 @ 16:13:
[...]
Dan heb je per klant een IP-adres nodig waar je Exim op poort 465 laat luisteren. (Samen met 25 en 587 voor TLS met STARTTLS.)

Geprobeerd; klant krijgt dan het self signed certificate gepresenteerd dat op de server staat.

STARTTLS schopt verkeer naar SMTP legacy poort 465? Heb ik wel even mee 'gespeeld' maar hielp niet in het ophalen van het juiste SSL-certificaat.

Exim kan daar prima tegen maar je doet iets raars zonder daar een goede reden voor te hebben. SMTP praat je op 25, 465 (legacy ssl voor outlook) en 587.

Oorzaak zit erin dat Apache SSL nog accepteert op dit moment. Maar toch zonde om dat af te moeten sluiten eigenlijk. Hoewel ik ook voordelen zie: veiliger omdat de poort niet standaard is en het haalt het domeinspecifieke certificaat op. Dat laatste is precies waar het mij om gaat.

Reden had ik al wel gemeld:
Ik wil dat elke klant mail ontvangt dat is encrypted dmv. het eigen, domeinspecifieke SSL-certificaat.
En niet, zoals nu, via het self signed certificaat dat op de server staat.
Zodat de klant zelf kan verifiëren dat emailverkeer niet alleen versleuteld is maar ook uniek versleuteld en via partijen die de klant kan nagaan en zelf bepalen of hij deze vertrouwd.
En zo nog wat redenen: minder kans op spamlisting wanneer 1 klant zich 'misdraagt' qua emailgebruik.

[...]
Dovecot is een MUA; doet niks met smtp.

ik ga even Googelen op MUA...

TNX voor de input guys

[ Voor 14% gewijzigd door JJ Le Funk op 05-11-2013 16:54 ]

[CyBeR]

[quote]MrJayMan schreef op dinsdag 05 november 2013 @ 16:23:
Ter verduidelijking:

• Elke klant heeft eigen FQDN + vast IP + SSL.
• De Linux-gebaseerde server is zowel web als mail server.
• [...] Geprobeerd; klant krijgt dan het self signed certificate gepresenteerd dat op de server staat.

Dan heb je exim niet goed geconfigureerd Tip:

# Set the certificate and key based on vhost.
tls_certificate = /etc/exim4/ssl/${smtp_active_hostname}.cer
tls_privatekey = /etc/exim4/ssl/${smtp_active_hostname}.key

(smtp_active_hostname moet je dan weer instellen adhv het ip-adres. Dat laat ik voor nu even als excercise to the reader.)

STARTTLS schopt verkeer naar SMTP legacy poort 465? Heb ik wel even mee 'gespeeld' maar hielp niet in het ophalen van het juiste SSL-certificaat.

Nee, STARTTLS is een manier om een cleartext-verbinding te upgraden naar TLS over dezelfde socket. 't is gewoon een soort 'ok en vanaf nu gaan we tls lullen!' commando.

[ Voor 6% gewijzigd door CyBeR op 05-11-2013 16:33 ]

[JJ Le Funk]

CyBeR schreef op dinsdag 05 november 2013 @ 16:32:
[...]
Dan heb je exim niet goed geconfigureerd Tip:

# Set the certificate and key based on vhost.
tls_certificate = /etc/exim4/ssl/${smtp_active_hostname}.cer
tls_privatekey = /etc/exim4/ssl/${smtp_active_hostname}.key

(smtp_active_hostname moet je dan weer instellen adhv het ip-adres. Dat laat ik voor nu even als excercise to the reader.)
[...]

dus t kan wel?! ik ga weer even snuffelen in de EXIM Config en VHost user folders...

[CyBeR]

Natuurlijk kan het. Exim is reteflexibel. Dat stukje haalde ik uit mijn config waarin ik ook twee verschillende certs gebruik.

Let wel: exim is niet zoals apache waar vhosts een standaardmogelijkheid zijn (aangezien dat binnen de wereld van smtp niet zo'n standaard gebeuren is.)

Exim kan zo ongeveer alles maar je moet 't wel zelf in elkaar zetten.

[ Voor 47% gewijzigd door CyBeR op 05-11-2013 16:50 ]