[PHP/E-mail] - Waarborgen inhoud/verzender automatische mail

[gvanh]

Goedemiddag,

Is er een mogelijk om - met behulp van PHP - een e-mail bericht te verzenden dat op de één of andere manier voor de ontvanger waarborgt dat de inhoud van het bericht onveranderd is, sinds het is verzonden, en dat waarborgt dat de verzender daadwerkelijk is wie hij zegt dat hij is. Het gaat om berichten die verzonden worden in het kader van een semi-overheidsorgaan, dat in het kader van regelgeving moet voldoen aan de eis dat e-mails die vanuit de webserver - als repons op een ingevuld webformulier - op één of andere manier qua inhoud en afzender (afzender is dus altijd dezelfde) gewaarborgd zijn.

Daarbij is het verder zo, dat de ontvangers niet een private/public key hebben die te gebruiken is; het is namelijk niet een afgebakende groep van potentiële ontvangers.

Ik weet niet zo goed in welke richting ik moet denken ... dus alle feedback is welkom.

[roeleboel]

Als de afzender (webserver dus) de email signt met zijn private key, kan iedereen toch adhv de publieke key van de webserver controleren dat die mail inderdaad vanaf de webserver komt?
De ontvanger heeft hiervoor zelf geen keypair nodig, die heeft genoeg met de publieke key van de afzender. (en die laatste staat uiteraard op publiek toegankelijke key-servers of zo)

[ Voor 11% gewijzigd door roeleboel op 19-11-2009 13:28 ]

[gertvdijk]

Wat roeleboel zegt. Daarop wil ik nog even aanvullen dat je dan wel zeker moet zijn van de juiste public key te hebben verspreid onder je ontvangers. Dus even iets met de fingerprint telefonisch controleren enzo.

[samo]

Of je kan een kopie van het bericht op de server toegankelijk maken. De IB-Groep doet dat bijvoorbeeld; de berichten zijn niet in de mail te lezen maar slechts in hun inbox. Soms wat omslachtig, maar het voldoet aan wat jij beschrijft.

[DiedX]

Afgezien van het waarom: volgens mij is dit niet mogelijk. Tenzij je de bezoeker (=browser) een javascript laat uitvoeren waarin het formulier gehashed wordt.

Er is geen garantie dat er niet met PHP wordt gekloot, dus er is geen garantie dat datgene wat de gebruiker invoert ook datgene is wat er gemailed wordt.

Maar even terug: welk probleem probeer je te tackelen?

[gvanh]

DiedX schreef op donderdag 19 november 2009 @ 13:37:
Maar even terug: welk probleem probeer je te tackelen?

Ja, goed punt. Heel eerlijk gezegd heb ik dat ook nog niet helemaal helder op het netvlies. Even hardop denkend:
- De ontvanger moet zeker weten dat de e-mail die hij krijgt daadwerkelijk afkomstig is van de organisatie
- De ontvanger moet zeker weten dat de inhoud van de e-mail (inclusief PDF-bijlage) is zoals deze verstuurd is door de organisatie.

Alternatief zou kunnen zijn om de PDF-bijlage met een bepaald certificaat te signeren, maar ik heb geen idee of zoiets mogelijk is met PHP, zonder dat er gebruik wordt gemaakt van iets van een Server-versie van een Adobe-Acrobat product (distiller of zo?).

Wat verder nog van belang is: de ontvanger is over het algemeen een persoon met een flinke dosis aversie tegen ICT-oplossingen en moet dus eigenlijk zonder (of: met zo min mogelijk) inspanningen het bericht kunnen ontvangen/openen.

[ Voor 12% gewijzigd door gvanh op 19-11-2009 13:44 . Reden: aanvulling ]

[gertvdijk]

DiedX schreef op donderdag 19 november 2009 @ 13:37:
Er is geen garantie dat er niet met PHP wordt gekloot, dus er is geen garantie dat datgene wat de gebruiker invoert ook datgene is wat er gemailed wordt.

Euhm dat de server wordt gehacked (met PHP rommelen) is niet bepaald een situatie die TS probeert te voorkomen hiermee.

DiedX schreef op donderdag 19 november 2009 @ 13:37:
Maar even terug: welk probleem probeer je te tackelen?

Dat zegt ie toch heel duidelijk? Voorkomen dat de mail onderweg vanaf de server naar de ontvanger niet geschonden is en aantoonbaar afkomstig is van die server. Dat kan dus met signing van de mail middels public/private keypairs.

[gertvdijk]

gvanh schreef op donderdag 19 november 2009 @ 13:42:
Even hardop denkend:
- De ontvanger moet zeker weten dat de e-mail die hij krijgt daadwerkelijk afkomstig is van de organisatie
- De ontvanger moet zeker weten dat de inhoud van de e-mail (inclusief PDF-bijlage) is zoals deze verstuurd is door de organisatie.

Gewoon de hele mail met GPG signen en dan ben je klaar toch? Geen afhankelijkheden van PDF en gewoon hele mail gesigned.
PEAR heeft een leuke GPG package voor PHP.

[ Voor 8% gewijzigd door gertvdijk op 19-11-2009 13:45 ]

[DiedX]

Het enige wat ik zelf kan bedenken is dat de gebruiker een mail krijgt met daarin een link. Als hij hierop drukt wordt de mail daadwerkelijk naar de ontvanger gestuurd. Je mag er niet vanuit gaan dat de gebruiker dan ook daadwerkelijk voor de organisatie werkt, maar iets meer zekerheid heb je dan wel.

Uitgaande van de huidige informatie (en mijn kennis) is dit probleem niet op te lossen. Een deelauthenticatie (= de gebruiker waarvoor hij zich uitgeeft) zou je met email af kunnen vangen, maar biedt nooit 100% zekerheid.

[DiedX]

gertvdijk schreef op donderdag 19 november 2009 @ 13:44:
[...]

Gewoon de hele mail met GPG signen en dan ben je klaar toch? Geen afhankelijkheden van PDF en gewoon hele mail gesigned.

Het enige wat je dan weet is dat de mail daadwerkelijk afkomstig is van de webserver. Niet meer dan dat...

[gertvdijk]

DiedX schreef op donderdag 19 november 2009 @ 13:47:
Het enige wat je dan weet is dat de mail daadwerkelijk afkomstig is van de webserver. Niet meer dan dat...

Je weet ook dat er niet is gerommeld met de inhoud! Lees je heel snel in in wat signing precies doet en geen onzin verkondigen.

quote: http://en.wikipedia.org/wiki/GNU_Privacy_Guard

It is also possible to add a cryptographic digital signature to a message, so the message integrity and sender can be verified, if a particular correspondence relied upon has not been corrupted.

@TS: tip - experimenteer zelf eerst eens met GPG op je desktop en de Enigmail plugin in Thunderbird. Als je het onder de knie hebt kan je het eenvoudig in je webapp bouwen.

[ Voor 39% gewijzigd door gertvdijk op 19-11-2009 13:52 ]

[DiedX]

gertvdijk schreef op donderdag 19 november 2009 @ 13:48:
[...]

Je weet ook dat er niet is gerommeld met de inhoud! Lees je heel snel in in wat signing precies doet en geen onzin verkondigen.

Sorry Gert,

Zie TS:

Is er een mogelijk om - met behulp van PHP - een e-mail bericht te verzenden dat op de één of andere manier voor de ontvanger waarborgt dat de inhoud van het bericht onveranderd is, sinds het is verzonden, en dat waarborgt dat de verzender daadwerkelijk is wie hij zegt dat hij is

Daaronder zegt de TS dat certificaten niet mogelijk zijn. Mag jij uitleggen hoe jij je gebruiker (dus degene die het formulier invult!) authenticeert met PGP.

Geen onzin. Je kan namelijk de gebruiker niet authenticeren hiermee. De (ongeauthenticeerde!) gebruiker vult een formulier in, waarmee de programmeur van alles kan doen voordat hij 'm (signed) verstuurd.

[gertvdijk]

DiedX schreef op donderdag 19 november 2009 @ 13:51:
Daaronder zegt de TS dat certificaten niet mogelijk zijn. Mag jij uitleggen hoe jij je gebruiker (dus degene die het formulier invult!) authenticeert met PGP.

Geen onzin. Je kan namelijk de gebruiker niet authenticeren hiermee. De (ongeauthenticeerde!) gebruiker vult een formulier in, waarmee de programmeur van alles kan doen voordat hij 'm (signed) verstuurd.

Ik lees het heel anders in de TS:

gvanh schreef op donderdag 19 november 2009 @ 13:18:
Is er een mogelijk om - met behulp van PHP - een e-mail bericht te verzenden dat op de één of andere manier voor de ontvanger waarborgt dat de inhoud van het bericht onveranderd is, sinds het is verzonden

Tot zover kan er geen misverstand bestaan.

gvanh schreef op donderdag 19 november 2009 @ 13:18:
en dat waarborgt dat de verzender daadwerkelijk is wie hij zegt dat hij is.

Hier kan ik er vanuit gaan dat de verzender de PHP applicatie is met als medium een e-mail naar de persoon/personen die dit soort mails moeten ontvangen. Degene die een webformulier invult is imo geen verzender van die e-mail. Die laag van communicatie dichtgooien vereist een heel andere aanpak dan de mail gaan signen/encrypten.

gvanh schreef op donderdag 19 november 2009 @ 13:18:
Het gaat om berichten die verzonden worden in het kader van een semi-overheidsorgaan, dat in het kader van regelgeving moet voldoen aan de eis dat e-mails die vanuit de webserver - als repons op een ingevuld webformulier - op één of andere manier qua inhoud en afzender (afzender is dus altijd dezelfde) gewaarborgd zijn.

Tja wat wil TS nu? Wat ik lees is dat er na het invullen van een webformulier een mail wordt verzonden naar iemand die het moet beantwoorden. Dat kan toch prima met GPG? De invuller van het webformulier staat hier toch geheel los van?
DiedX, jij leest duidelijk heel wat anders uit de TS dan ik.

[ Voor 5% gewijzigd door gertvdijk op 19-11-2009 13:59 ]

[DiedX]

gertvdijk schreef op donderdag 19 november 2009 @ 13:57:
Hier kan ik er vanuit gaan dat de verzender de PHP applicatie is met als medium een e-mail naar de persoon/personen die dit soort mails moeten ontvangen.

...

DiedX, jij leest duidelijk heel wat anders uit de TS dan ik.

Dan zijn we het daarover eens. Afgezien van dat: wat is het praktisch nut dat de ontvangende partij weet dat er niet gerommeld is met de email? Als ik daaraan zou twijfelen dan bel ik degene op.

Maar inderdaad: TS, wat is de bedoeling?

[gertvdijk]

DiedX schreef op donderdag 19 november 2009 @ 14:00:
Dan zijn we het daarover eens. Afgezien van dat: wat is het praktisch nut dat de ontvangende partij weet dat er niet gerommeld is met de email? Als ik daaraan zou twijfelen dan bel ik degene op.

Het is geen rocket science om de output van een webformulier na te maken en de afzender (From-header) te faken. Bovendien gaat mail over het grote boze internet en door mailservers die je per definitie niet kan vertrouwen. Dus ongeveer dezelfde reden als SSL alleen dan net effe wat anders.
Hiermee kom je terug op het algemene nut van GPG en de Enigmail plugin van Thunderbird. Dus ik zou me daarin verdiepen als je het nut niet snapt

[gvanh]

Daaronder zegt de TS dat certificaten niet mogelijk zijn. Mag jij uitleggen hoe jij je gebruiker (dus degene die het formulier invult!) authenticeert met PGP.

Geen onzin. Je kan namelijk de gebruiker niet authenticeren hiermee. De (ongeauthenticeerde!) gebruiker vult een formulier in, waarmee de programmeur van alles kan doen voordat hij 'm (signed) verstuurd.

Ok, ik snap dat onduidelijkheid. Volgens mij is het PGP verhaal inderdaad wat ik nodig heb. Het gaat erom dat de webserver daadwerkelijk de webserver is die de e-mail verzonden heeft. Ik ga er dus even vanuit dat alles wat de gebruiker in het formulier heeft ingevuld en zoals het verzonden is vanaf de webserver in ieder geval veilig is (gaat ook via SSL). Degene die het formulier heeft ingevuld krijgt zelf een e-mail met een samenvatting van wat hij heeft ingevuld en de (semi-)overheidsinstantie krijgt een e-mail met daarin de door de gebruiker ingevulde gegevens. De twee ontvangers zouden met behulp van de PGP signing kunnen controleren dat de e-mail daadwerkelijk van de webserver afkomstig is (en dus niet van een kwaadwillende derde die de headers heeft aangepast) en dat de inhoud van het bericht niet is veranderd sinds het door de webserver is verstuurd. Op die manier kan de inhoud van het bericht later als "bewijs" (voor zover dat nuttig is hoor) kunnen dienen, wanneer er onenigheid is over wat er door de bezoeker is ingevuld in het formulier.

Dan is alleen nog even de vraag hoe ik de publieke sleutel bij de gebruiker krijg op een zo laagdrempelig mogelijke wijze. Is er een key-algoritme dat (ook) door veelgebruikte e-mailclients wordt ondersteund, zoals Outlook (Express) en Hotmail/Gmail?

[DiedX]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Je hoeft me niet alles uit te leggen. Als je even creatief gegoogled had dan had je al gevonden in welke industrie ik werkzaam ben. Het wordt een beetje irritant dat je alles denkt te weten van GnuPG/PGP en daarin de enige denkt te zijn.

Ik zeg je nogmaals dat ik geen veiligheid garandeer, maar als je gebruik maakt van goede hashes, en niet 100% goedgelovig bent, dan kan je zien dat met een beetje geluk het mailadres waar je de testmail naar toe stuurt bestaat. Je zal sowieso nog iets van training moeten geven om dat goed te laten lezen.

Aan TS: de versturende partijen, hebben die wel standaard domeinnamen?

Dus mijn voorstel zou zijn:

* Verstuurder vult een formulier in. Hierin zijn standaard blaat, en zijn mailadres.
* Webserver slaat bovenstaande op in een database, en stuurt een mail naar het gegeven mailadres. Hierin het formulier, en een link met een hash. Uiteraard gaat deze link naar dezelfde webserver;
* Versturende partij klikt op de link in de mail;
* Webserver kijkt of de hash bestaat, en zo ja, geeft het mailtje vrij. Deze wordt verstuurd naar de ontvanger.

Veilig? Nee. Iemand die traffic kan sniffen kan de hash achterhalen, en de mail vrijgeven. Als ik verstuur naar [e-mail] komt hij ook bij mij aan, gebruikerstraining dus. Ook is er ruimte voor DNS-Spoofing, flooding en weet ik veel meer.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (Darwin)

iEYEARECAAYFAksFRk4ACgkQu90rg/0JPPrFTgCgsNLq1D4NpV16Mtk3+oeP5gGs
cjQAoMvszp/bccMlYCLgeKDIt4Sc8MCp
=A9uy
-----END PGP SIGNATURE-----

[DiedX]

gvanh schreef op donderdag 19 november 2009 @ 14:17:
Dan is alleen nog even de vraag hoe ik de publieke sleutel bij de gebruiker krijg op een zo laagdrempelig mogelijke wijze. Is er een key-algoritme dat (ook) door veelgebruikte e-mailclients wordt ondersteund, zoals Outlook (Express) en Hotmail/Gmail?

S/MIME is dan een oplossing. Ik weet daar zelf weinig van, en vermoed dat Hotmail dat niet ondersteund. Maar de ontvangende partij weet dan nog steeds niet zeker dat de verzendende partij de partij is waarvoor zij zich uitgeeft...

[gertvdijk]

DiedX schreef op donderdag 19 november 2009 @ 14:21:
Het wordt een beetje irritant dat je alles denkt te weten van GnuPG/PGP en daarin de enige denkt te zijn.

Dat denk ik helemaal niet.
Jij stelde dat je het GPG signing niet de inhoud van de mail op integriteit kan controleren en dat is pertinent ontwaar mits de definitie van de versturende partij ook ligt bij de persoon die de inhoud creëert (de webserver creëert en verstuurt de e-mail - niet de invullende bezoeker). Juist die definitie hadden we een verschil over van interpretatie vanuit de TS. Googlen naar de CV van elke tweaker die hier post doe ik niet en veronderstellen dat ik dat wel doe en daarmee je kennis/kwalificaties weet vind ik vreemd.

DiedX schreef op donderdag 19 november 2009 @ 14:21:
* Verstuurder vult een formulier in. Hierin zijn standaard blaat, en zijn mailadres.
* Webserver slaat bovenstaande op in een database, en stuurt een mail naar het gegeven mailadres. Hierin het formulier, en een link met een hash. Uiteraard gaat deze link naar dezelfde webserver;
* Versturende partij klikt op de link in de mail;
* Webserver kijkt of de hash bestaat, en zo ja, geeft het mailtje vrij. Deze wordt verstuurd naar de ontvanger.

Het enige wat je hiermee toevoegt aan de hele procedure is dat je nu weet dat het e-mailadres wat de bezoeker invult bestaat. Meer niet en het is totaal niet het probleem van de TS.

DiedX schreef op donderdag 19 november 2009 @ 14:21:
Veilig? Nee. Iemand die traffic kan sniffen kan de hash achterhalen, en de mail vrijgeven. Als ik verstuur naar [e-mail] komt hij ook bij mij aan, gebruikerstraining dus. Ook is er ruimte voor DNS-Spoofing, flooding en weet ik veel meer.

En phishing niet te vergeten. Dus inderdaad; veilig/waterdicht is het nooit als je niet ook de gebruiker kan vertrouwen. Maar het komt wel tegemoet aan de richtlijnen die zijn opgesteld.

gvanh schreef op donderdag 19 november 2009 @ 14:17:
De twee ontvangers zouden met behulp van de PGP signing kunnen controleren dat de e-mail daadwerkelijk van de webserver afkomstig is (en dus niet van een kwaadwillende derde die de headers heeft aangepast) en dat de inhoud van het bericht niet is veranderd sinds het door de webserver is verstuurd.

Tot zover eens.

gvanh schreef op donderdag 19 november 2009 @ 14:17:
Op die manier kan de inhoud van het bericht later als "bewijs" (voor zover dat nuttig is hoor) kunnen dienen, wanneer er onenigheid is over wat er door de bezoeker is ingevuld in het formulier.

Mits je een "Ja ik verklaar dit ingevuld te hebben" OK-link maakt in de mail die de bezoeker ontvangt en die ook aanklikt.

gvanh schreef op donderdag 19 november 2009 @ 14:17:
Dan is alleen nog even de vraag hoe ik de publieke sleutel bij de gebruiker krijg op een zo laagdrempelig mogelijke wijze. Is er een key-algoritme dat (ook) door veelgebruikte e-mailclients wordt ondersteund, zoals Outlook (Express) en Hotmail/Gmail?

Mailclients zonder GPG ondersteuning komen er bij mij niet in. Ik zou zeggen: leg die verantwoordelijkheid bij de bezoeker. Hij krijgt in elk geval de kans om het te verifiëren (mits hij niet-geautomatiseerd de juistheid van de key kan controleren, bijv. telefonisch) of de mail niet onderweg is aangeraakt. Als de ontvanger hotmail gebruikt en alleen de webinterface ervan wil gebruiken is hij mogelijk niet in staat hiervan gebruik te maken, maar dan moet hij maar een fatsoenlijke mailclient gebruiken. Als je dit van tevoren meldt kunnen mensen je dit niet weigeren.
Overigens is het alternatief S/MIME iets breder ondersteund in clients, maar daarmee wordt berust op eenzelfde trustmodel als bij SSL certificaten als ik me niet vergis. Daarmee vertrouw je dus niet expliciet de server, maar de uitgever van het certificaat die jou weer zegt te vertrouwen. Maar precies datzelfde principe heb je al met SSL, zoals je al bekend is denk ik.

[ Voor 34% gewijzigd door gertvdijk op 19-11-2009 14:49 ]

[gvanh]

Mailclients zonder GPG ondersteuning komen er bij mij niet in. Ik zou zeggen: leg die verantwoordelijkheid bij de bezoeker. Hij krijgt in elk geval de kans om het te verifiëren (mits hij niet-geautomatiseerd de juistheid van de key kan controleren, bijv. telefonisch) of de mail niet onderweg is aangeraakt.

Kan ik hieruit opmaken dat Outlook (Express) in ieder geval wel GPG ondersteunen?

Helaas zal het bulk van de ontvangers toch met Outlook werken, en de groep met (potentiële) gebruikers is helaas te groot (en te autonoom én te eigenwijs) om hen ook maar iets te kunnen opleggen als het gaat om software-gebruik.

Enfin ... ik ga even duiken in GPG ... alhoewel ik uit de PEAR omschrijving van het PGP-pakket begrijp dat het alleen bedoeld is voor encryptie met een public key en niet met een private key ... maar dat is even op het eerste snelle lezen.

[gertvdijk]

gvanh schreef op donderdag 19 november 2009 @ 15:37:
Kan ik hieruit opmaken dat Outlook (Express) in ieder geval wel GPG ondersteunen?

Nee, dat lees je dan verkeerd. Ik zou zeggen: google het eens!

gvanh schreef op donderdag 19 november 2009 @ 15:37:
Helaas zal het bulk van de ontvangers toch met Outlook werken, en de groep met (potentiële) gebruikers is helaas te groot (en te autonoom én te eigenwijs) om hen ook maar iets te kunnen opleggen als het gaat om software-gebruik.

Ja, dan is het controleren van inhoud sowieso niet doenlijk als je de gebruikers niet kan instrueren hoe dit moet. Sorry, maar dan is er geen beginnen aan. Je kan ook niet zonder md5 tool de md5sum controleren aan de andere kant. Kortom: de mensen die dit echt nodig hebben moeten dit gewoon geïnstalleerd krijgen op hun werkplek (schop systeembeheerder) en ermee leren werken; dat is hun werk. Als het beleid daaromtrent niet afdoende is, is het implementeren van een dergelijk systeem ook totaal niet zinvol imo.

gvanh schreef op donderdag 19 november 2009 @ 15:37:
Enfin ... ik ga even duiken in GPG ... alhoewel ik uit de PEAR omschrijving van het PGP-pakket begrijp dat het alleen bedoeld is voor encryptie met een public key en niet met een private key ... maar dat is even op het eerste snelle lezen.

Nou als je even naar beneden had gescrolld op de examples pagina had je allang gezien dat je er ook mee kan signen. (duurt korter dan hier typen dat je denkt dat het er niet mee kan) Lijkt me ook nogal wiedes, dat is niet echt iets wat moeilijk of anders te implementeren is.

Overigens ondersteunt het webmail platform Horde/IMP GPG (encrypt, signing, eigen keypair, etc) out-of-the-box en zou je eens in die source kunnen duiken hoe ze dat hebben gedaan.

[ Voor 15% gewijzigd door gertvdijk op 19-11-2009 15:47 ]

[gvanh]

Dan nog even een heel andere insteek. Wat nu als ik iets van een certificaat installeer op de server ... kan ik dan dat certificaat "hangen" aan de e-mail, zodat gebruikers kunnen zien dat de e-mail afkomstig is van het betreffende certificaat?

[gertvdijk]

gvanh schreef op donderdag 19 november 2009 @ 15:54:
Dan nog even een heel andere insteek. Wat nu als ik iets van een certificaat installeer op de server ... kan ik dan dat certificaat "hangen" aan de e-mail, zodat gebruikers kunnen zien dat de e-mail afkomstig is van het betreffende certificaat?

Dat lijkt mij een mooi voorbeeld van "Wij van WC eend..." toegepast op signing.
Je controleert daarmee namelijk het bericht met zichzelf.
We lopen niet voor niks zo te hameren om het controleren van de public key in geval van GPG. Als je de public key of het certificaat mee gaat sturen met het bericht zelf is het voor een man-in-the-middle alleen maar makkelijker geworden. Immers, evil-person stuurt gewoon zelf zijn eigen gesignde bericht mee met bijbehorende public key/certificaat en dat komt natuurlijk altijd door de verificatie heen (want je controleert dan niet meer expliciet de herkomst, maar of het bericht is gesigned met de key/cert die bij het bericht zelf zit).

Bij S/MIME vertrouwt de ontvanger de CA die het certificaat heeft gesigned en daarmee is het bij een certificaat juist wel normaal om dat te doen, maar daarmee is het dus minder strikt dat het afkomstig is van die webserver. Een gemiddelde mailclient kijkt dan of het S/MIME gesignde bericht hoort bij een vertrouwd certificaat, niet of het ook daadwerkelijk precies die is die jij op die server hebt geïnstalleerd: vergelijkbaar met SSL over HTTP in je browser. Bij GPG ligt het veel eenvoudiger: je hangt alleen de enige juiste public key in de keyring van de ontvanger en de header van het bericht kleurt groen als de validatie geslaagd is (voorbeeld Enigmail in Thunderbird).

Oftewel: denk even zelf na, gewoon logisch, common sense. En probeer vooral zelf dingen uit. Volgens mij heb je ook nog niet opgezocht wat S/MIME is als je nu vraagt hoe je een SSL cert aan een mail hangt enzo.