S/MIME Partie 4 : Collecte des clés publiques des destinataires facilement – avec les webhooks de relais entrant SparkPost
Oiseau
1 févr. 2019
1 min read
Points Clés
Prémisse : Envoyer un e-mail chiffré S/MIME n'est pas difficile une fois que vous pouvez automatiquement recueillir la clé publique de chaque destinataire. Ce post comble cette lacune en utilisant SparkPost Inbound Relay Webhooks pour recevoir les e-mails signés, extraire les certificats et les stocker pour un chiffrement ultérieur.
Objectif : Construire un service webhook basé sur Flask qui écoute les messages signés entrants, les valide (vérifications DKIM + certificat), et écrit en toute sécurité chaque clé publique sur le disque pour être utilisé dans le courrier sécurisé sortant.
Points forts :
Problème : L'échange manuel de clés ne s'adapte pas aux e-mails générés par les applications.
Solution : Invitez les utilisateurs à envoyer un e-mail signé ; le webhook entrant analyse automatiquement et stocke leur certificat PEM.
Étapes de configuration :
Configurez un Domaine Entrant et les enregistrements MX (par exemple, inbound.yourdomain.com).
Créez un Inbound Relay Webhook via l'API SparkPost pointant vers le point de terminaison de votre application.
Déployez une petite application Flask (webapp.py) en utilisant la configuration de webapp.ini.
Consigner de manière exhaustive pour la transparence ; intégrer Pytest + Travis CI pour une validation automatisée.
Mesures de sécurité :
Vérifier les signatures DKIM et l'authenticité des messages.
Valider la chaîne de confiance du certificat avant de stocker.
Utiliser un jeton d'authentification secret dans les en-têtes du webhook.
Résultat :
Chaque message entrant valide crée un fichier de certificat tel que bob.lumreeker@gmail.com.crt.
Une fois stockées, ces clés permettent des réponses chiffrées en utilisant des scripts antérieurs des parties 2 et 3.
Points forts des Q&A
Pourquoi la collecte des clés des destinataires est-elle si critique pour S/MIME ?
Parce que le chiffrement nécessite la clé publique de chaque destinataire; automatiser cette étape permet à toute application d'envoyer des courriers sécurisés sans échange manuel.
Comment le SparkPost Inbound Relay Webhook simplifie-t-il la collecte clé ?
Il convertit tout e-mail entrant signé en une charge utile JSON structurée, permettant à votre application d'analyser et de conserver des certificats de manière programmatique.
Quels sont les garde-fous qui empêchent le spoofing ou les soumissions indésirables ?
Le service valide les signatures DKIM, applique les jetons d'authentification, et rejette les messages malformés ou non signés.
Où sont stockés les certificats et sous quel format ?
Ils sont écrits sur le disque au format PEM (fichiers
.crt), prêts à être utilisés par la chaîne d'outils de signature/chiffrement construite dans les parties précédentes.Quel est le workflow du développeur ?
Exécutez l'application Flask, vérifiez avec Postman en utilisant la charge utile d'exemple fournie, puis connectez-la au webhook en direct de SparkPost pour une opération continue.
Conclusion générale ?
La gestion des clés S/MIME peut être entièrement automatisée avec quelques lignes de Python et les API SparkPost—apportant un chiffrement évolutif à tout flux de travail d'e-mails générés par des applications.
Dans la partie 1, nous avons eu un aperçu rapide de S/MIME, en examinant la signature et le chiffrement de nos flux de messages à travers une gamme de clients de messagerie. La partie 2 nous a guidés à travers un outil en ligne de commande simple pour signer et crypter les e-mails, puis les envoyer via SparkPost. La partie 3 a montré comment injecter des flux de courrier sécurisés dans des plateformes sur site telles que Port25 PowerMTA et Momentum.
Dans cette série, nous avons vu comment inclure une signature S/MIME est assez simple. Envoyer du courrier chiffré S/MIME est plus complexe car vous devez obtenir les clés publiques des destinataires. C’est une chose lorsque vous utilisez un client de messagerie pour les humains tel que Thunderbird - mais comment cela fonctionne-t-il avec les flux d'e-mails générés par des applications ? Les e-mails générés par des applications, comme ceux utilisés par les plateformes de rencontres, nécessitent une stratégie soignée pour maximiser l'engagement. Voyez comment les applications de rencontre créent des expériences d'e-mail déclenchées captivantes.
Mais attendez - il y a un autre chemin vers la Comté pour obtenir ces clés. Votre service peut inviter vos clients (par e-mail, bien sûr) à vous renvoyer un courrier signé à une adresse de service client connue. En utilisant les pouvoirs magiques des webhooks de SparkPost Inbound Relay, nous allons extraire et stocker cette clé publique pour que vous puissiez l'utiliser.
Nous pouvons résumer cela dans un cas d'utilisation simple :
En tant que destinataire de messages, je fournis à votre service ma signature électronique personnelle par e-mail, afin que, à l'avenir, les e-mails puissent m'être envoyés sous forme chiffrée S/MIME.
A partir de cela, tirons quelques exigences plus détaillées :
Nous avons besoin d'un service de réception d'e-mails toujours actif et fiable pour recevoir ces e-mails signés.
Il ne devrait y avoir aucune exigence particulière sur le format de l'e-mail, si ce n'est qu'il doit contenir une signature S/MIME.
Parce que n'importe qui peut essayer d'envoyer un courrier à ce service, il doit être conçu de manière défensive, par exemple, pour rejeter les messages de «spoof» provenant de mauvais acteurs. Il devra y avoir plusieurs couches de vérification.
Si tout est en ordre, le service stockera le certificat dans un fichier, en utilisant le format texte brut bien connu Privacy-Enhanced Mail (PEM).
Il y a quelques exigences non fonctionnelles :
Les services de webhook machine à machine peuvent être difficiles à visualiser juste à partir des réponses à ce qui se passe à l'intérieur. Le service doit fournir des journaux applicatifs au niveau humain étendus. En particulier, l'analyse et la vérification des certificats doivent être enregistrées.
Nous ajoutons des cas de test pour les processus internes de l'application, en utilisant le charmant cadre Pytest, et exécutons ces tests automatiquement lors de l'enregistrement utilisant l'intégration Travis CI avec GitHub.
D'accord – commençons !
Dans la partie 1, nous avons eu un aperçu rapide de S/MIME, en examinant la signature et le chiffrement de nos flux de messages à travers une gamme de clients de messagerie. La partie 2 nous a guidés à travers un outil en ligne de commande simple pour signer et crypter les e-mails, puis les envoyer via SparkPost. La partie 3 a montré comment injecter des flux de courrier sécurisés dans des plateformes sur site telles que Port25 PowerMTA et Momentum.
Dans cette série, nous avons vu comment inclure une signature S/MIME est assez simple. Envoyer du courrier chiffré S/MIME est plus complexe car vous devez obtenir les clés publiques des destinataires. C’est une chose lorsque vous utilisez un client de messagerie pour les humains tel que Thunderbird - mais comment cela fonctionne-t-il avec les flux d'e-mails générés par des applications ? Les e-mails générés par des applications, comme ceux utilisés par les plateformes de rencontres, nécessitent une stratégie soignée pour maximiser l'engagement. Voyez comment les applications de rencontre créent des expériences d'e-mail déclenchées captivantes.
Mais attendez - il y a un autre chemin vers la Comté pour obtenir ces clés. Votre service peut inviter vos clients (par e-mail, bien sûr) à vous renvoyer un courrier signé à une adresse de service client connue. En utilisant les pouvoirs magiques des webhooks de SparkPost Inbound Relay, nous allons extraire et stocker cette clé publique pour que vous puissiez l'utiliser.
Nous pouvons résumer cela dans un cas d'utilisation simple :
En tant que destinataire de messages, je fournis à votre service ma signature électronique personnelle par e-mail, afin que, à l'avenir, les e-mails puissent m'être envoyés sous forme chiffrée S/MIME.
A partir de cela, tirons quelques exigences plus détaillées :
Nous avons besoin d'un service de réception d'e-mails toujours actif et fiable pour recevoir ces e-mails signés.
Il ne devrait y avoir aucune exigence particulière sur le format de l'e-mail, si ce n'est qu'il doit contenir une signature S/MIME.
Parce que n'importe qui peut essayer d'envoyer un courrier à ce service, il doit être conçu de manière défensive, par exemple, pour rejeter les messages de «spoof» provenant de mauvais acteurs. Il devra y avoir plusieurs couches de vérification.
Si tout est en ordre, le service stockera le certificat dans un fichier, en utilisant le format texte brut bien connu Privacy-Enhanced Mail (PEM).
Il y a quelques exigences non fonctionnelles :
Les services de webhook machine à machine peuvent être difficiles à visualiser juste à partir des réponses à ce qui se passe à l'intérieur. Le service doit fournir des journaux applicatifs au niveau humain étendus. En particulier, l'analyse et la vérification des certificats doivent être enregistrées.
Nous ajoutons des cas de test pour les processus internes de l'application, en utilisant le charmant cadre Pytest, et exécutons ces tests automatiquement lors de l'enregistrement utilisant l'intégration Travis CI avec GitHub.
D'accord – commençons !
Dans la partie 1, nous avons eu un aperçu rapide de S/MIME, en examinant la signature et le chiffrement de nos flux de messages à travers une gamme de clients de messagerie. La partie 2 nous a guidés à travers un outil en ligne de commande simple pour signer et crypter les e-mails, puis les envoyer via SparkPost. La partie 3 a montré comment injecter des flux de courrier sécurisés dans des plateformes sur site telles que Port25 PowerMTA et Momentum.
Dans cette série, nous avons vu comment inclure une signature S/MIME est assez simple. Envoyer du courrier chiffré S/MIME est plus complexe car vous devez obtenir les clés publiques des destinataires. C’est une chose lorsque vous utilisez un client de messagerie pour les humains tel que Thunderbird - mais comment cela fonctionne-t-il avec les flux d'e-mails générés par des applications ? Les e-mails générés par des applications, comme ceux utilisés par les plateformes de rencontres, nécessitent une stratégie soignée pour maximiser l'engagement. Voyez comment les applications de rencontre créent des expériences d'e-mail déclenchées captivantes.
Mais attendez - il y a un autre chemin vers la Comté pour obtenir ces clés. Votre service peut inviter vos clients (par e-mail, bien sûr) à vous renvoyer un courrier signé à une adresse de service client connue. En utilisant les pouvoirs magiques des webhooks de SparkPost Inbound Relay, nous allons extraire et stocker cette clé publique pour que vous puissiez l'utiliser.
Nous pouvons résumer cela dans un cas d'utilisation simple :
En tant que destinataire de messages, je fournis à votre service ma signature électronique personnelle par e-mail, afin que, à l'avenir, les e-mails puissent m'être envoyés sous forme chiffrée S/MIME.
A partir de cela, tirons quelques exigences plus détaillées :
Nous avons besoin d'un service de réception d'e-mails toujours actif et fiable pour recevoir ces e-mails signés.
Il ne devrait y avoir aucune exigence particulière sur le format de l'e-mail, si ce n'est qu'il doit contenir une signature S/MIME.
Parce que n'importe qui peut essayer d'envoyer un courrier à ce service, il doit être conçu de manière défensive, par exemple, pour rejeter les messages de «spoof» provenant de mauvais acteurs. Il devra y avoir plusieurs couches de vérification.
Si tout est en ordre, le service stockera le certificat dans un fichier, en utilisant le format texte brut bien connu Privacy-Enhanced Mail (PEM).
Il y a quelques exigences non fonctionnelles :
Les services de webhook machine à machine peuvent être difficiles à visualiser juste à partir des réponses à ce qui se passe à l'intérieur. Le service doit fournir des journaux applicatifs au niveau humain étendus. En particulier, l'analyse et la vérification des certificats doivent être enregistrées.
Nous ajoutons des cas de test pour les processus internes de l'application, en utilisant le charmant cadre Pytest, et exécutons ces tests automatiquement lors de l'enregistrement utilisant l'intégration Travis CI avec GitHub.
D'accord – commençons !
1. Aperçu de la solution
Voici à quoi ressemblera la solution globale.
Voici à quoi ressemblera la solution globale.
Voici à quoi ressemblera la solution globale.
2. Installation, configuration et démarrage de l'application web
Nous allons commencer avec cette partie, afin de la tester entièrement avant de configurer les relais pour webhooks entrants.
L'application web est incluse dans le même projet GitHub que les parties 1 à 3, donc si vous avez suivi ces parties, vous l'avez déjà. Voici les nouveaux éléments :
Programme readSMIMEsig.py – lire un email et analyser les certificats intermédiaires et utilisateurs.
Programme webapp.py – application web simple compatible Flask pour utilisation avec les SparkPost Inbound Relay Webhooks.
webapp.ini – fichier de configuration pour ce qui précède. Un fichier de config permet de transmettre facilement les mêmes valeurs aux applications en ligne de commande et web.
Vous devez vous assurer que votre hôte a le bon numéro de port TCP ouvert aux requêtes entrantes du monde extérieur afin que SparkPost puisse envoyer des messages à votre application. Si vous êtes hébergé sur AWS EC2, par exemple, vous devrez configurer le Groupe de Sécurité de votre instance.
Les instructions pour la configuration et le démarrage de l'application web sont fournies dans notre guide d'installation – c’est assez facile. Pour vérifier que votre application fonctionne et est accessible depuis le monde extérieur, vous pouvez envoyer des requêtes (vides) depuis un autre hôte en utilisant curl, par exemple :
curl -X POST https://app.trymsys.net:8855/
Vous devriez voir une réponse comme :
{"message":"Unknown Content-Type in request headers"}
C'est une bonne chose – votre application fonctionne !
Dans webapp.log sur votre hôte, vous verrez une sortie similaire à ceci :
2019-01-15 00:11:07,575,root,INFO,Request from 38.96.5.10,scheme=https,path=/ 2019-01-15 00:11:07,575,root,INFO,| len(headers)=3,len(body)=None 2019-01-15 00:11:07,575,root,INFO,| Unknown Content-Type: None
Pour vous aider à jouer avec des données réelles dans votre application immédiatement, vous pouvez importer cette requête Postman spécifique depuis le dépôt du projet. Cela simule ce que votre compte SparkPost fera, c’est-à-dire qu'il envoie un https POST contenant un email avec un certificat spécifique et valable (appartenant à un compte de test à moi) à votre application.
Vous devez simplement changer l'adresse cible dans la requête (dans le cadre gris ci-dessus) pour correspondre à votre installation. Si vous avez changé la valeur de l'token dans webapp.ini, ajustez la valeur de l'entête dans Postman pour correspondre.
Si votre application fonctionne, vous verrez une réponse "200 OK" dans Postman. Le fichier webapp.log de votre hôte contiendra une sortie comme celle-ci :
2019-01-15 00:11:48,554,root,INFO,Request from 38.96.5.10,scheme=https,path=/ 2019-01-15 00:11:48,554,root,INFO,| len(headers)=10,len(body)=14778 2019-01-15 00:11:48,555,root,INFO,| msg_from=bob.lumreeker@gmail.com,rcpt_to=secureme@inbound.thetucks.com,len(email_rfc822)=9223 2019-01-15 00:11:48,599,root,INFO,| from=bob.lumreeker@gmail.com,DKIM passed 2019-01-15 00:11:48,600,root,INFO,| content-type=multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010908020707040304020406",content-description=None 2019-01-15 00:11:48,600,root,INFO,| content-type=text/plain; charset=utf-8; format=flowed,content-description=None 2019-01-15 00:11:48,600,root,INFO,| content-type=application/pkcs7-signature; name="smime.p7s",content-description=S/MIME Cryptographic Signature 2019-01-15 00:11:48,600,root,INFO,| filename=smime.p7s,bytes=3998 2019-01-15 00:11:48,601,root,INFO,| Certificate: subject email_address=['bob.lumreeker@gmail.com'],not_valid_before=2018-10-03 00:00:00,not_valid_after=2019-10-03 23:59:59,hash_algorithm=sha256,key_size=2048 bytes, issuer={'countryName': 'GB', 'stateOrProvinceName': 'Greater Manchester', 'localityName': 'Salford', 'organizationName': 'COMODO CA Limited', 'commonName': 'COMODO RSA Client Authentication and Secure Email CA'} 2019-01-15 00:11:48,602,root,INFO,| Certificate: subject email_address=[],not_valid_before=2013-01-10 00:00:00,not_valid_after=2028-01-09 23:59:59,hash_algorithm=sha384,key_size=2048 bytes, issuer={'countryName': 'GB', 'stateOrProvinceName': 'Greater Manchester', 'localityName': 'Salford', 'organizationName': 'COMODO CA Limited', 'commonName': 'COMODO RSA Certification Authority'} 2019-01-15 00:11:48,616,root,INFO,| written file ./bob.lumreeker@gmail.com.crt,bytes=1870,ok=True
Pour une vérification rapide, cherchez la dernière ligne – si elle indique "written file", alors tout va bien. Le reste montre le processus de contrôle DKIM et de validation du certificat.
Nous allons commencer avec cette partie, afin de la tester entièrement avant de configurer les relais pour webhooks entrants.
L'application web est incluse dans le même projet GitHub que les parties 1 à 3, donc si vous avez suivi ces parties, vous l'avez déjà. Voici les nouveaux éléments :
Programme readSMIMEsig.py – lire un email et analyser les certificats intermédiaires et utilisateurs.
Programme webapp.py – application web simple compatible Flask pour utilisation avec les SparkPost Inbound Relay Webhooks.
webapp.ini – fichier de configuration pour ce qui précède. Un fichier de config permet de transmettre facilement les mêmes valeurs aux applications en ligne de commande et web.
Vous devez vous assurer que votre hôte a le bon numéro de port TCP ouvert aux requêtes entrantes du monde extérieur afin que SparkPost puisse envoyer des messages à votre application. Si vous êtes hébergé sur AWS EC2, par exemple, vous devrez configurer le Groupe de Sécurité de votre instance.
Les instructions pour la configuration et le démarrage de l'application web sont fournies dans notre guide d'installation – c’est assez facile. Pour vérifier que votre application fonctionne et est accessible depuis le monde extérieur, vous pouvez envoyer des requêtes (vides) depuis un autre hôte en utilisant curl, par exemple :
curl -X POST https://app.trymsys.net:8855/
Vous devriez voir une réponse comme :
{"message":"Unknown Content-Type in request headers"}
C'est une bonne chose – votre application fonctionne !
Dans webapp.log sur votre hôte, vous verrez une sortie similaire à ceci :
2019-01-15 00:11:07,575,root,INFO,Request from 38.96.5.10,scheme=https,path=/ 2019-01-15 00:11:07,575,root,INFO,| len(headers)=3,len(body)=None 2019-01-15 00:11:07,575,root,INFO,| Unknown Content-Type: None
Pour vous aider à jouer avec des données réelles dans votre application immédiatement, vous pouvez importer cette requête Postman spécifique depuis le dépôt du projet. Cela simule ce que votre compte SparkPost fera, c’est-à-dire qu'il envoie un https POST contenant un email avec un certificat spécifique et valable (appartenant à un compte de test à moi) à votre application.
Vous devez simplement changer l'adresse cible dans la requête (dans le cadre gris ci-dessus) pour correspondre à votre installation. Si vous avez changé la valeur de l'token dans webapp.ini, ajustez la valeur de l'entête dans Postman pour correspondre.
Si votre application fonctionne, vous verrez une réponse "200 OK" dans Postman. Le fichier webapp.log de votre hôte contiendra une sortie comme celle-ci :
2019-01-15 00:11:48,554,root,INFO,Request from 38.96.5.10,scheme=https,path=/ 2019-01-15 00:11:48,554,root,INFO,| len(headers)=10,len(body)=14778 2019-01-15 00:11:48,555,root,INFO,| msg_from=bob.lumreeker@gmail.com,rcpt_to=secureme@inbound.thetucks.com,len(email_rfc822)=9223 2019-01-15 00:11:48,599,root,INFO,| from=bob.lumreeker@gmail.com,DKIM passed 2019-01-15 00:11:48,600,root,INFO,| content-type=multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010908020707040304020406",content-description=None 2019-01-15 00:11:48,600,root,INFO,| content-type=text/plain; charset=utf-8; format=flowed,content-description=None 2019-01-15 00:11:48,600,root,INFO,| content-type=application/pkcs7-signature; name="smime.p7s",content-description=S/MIME Cryptographic Signature 2019-01-15 00:11:48,600,root,INFO,| filename=smime.p7s,bytes=3998 2019-01-15 00:11:48,601,root,INFO,| Certificate: subject email_address=['bob.lumreeker@gmail.com'],not_valid_before=2018-10-03 00:00:00,not_valid_after=2019-10-03 23:59:59,hash_algorithm=sha256,key_size=2048 bytes, issuer={'countryName': 'GB', 'stateOrProvinceName': 'Greater Manchester', 'localityName': 'Salford', 'organizationName': 'COMODO CA Limited', 'commonName': 'COMODO RSA Client Authentication and Secure Email CA'} 2019-01-15 00:11:48,602,root,INFO,| Certificate: subject email_address=[],not_valid_before=2013-01-10 00:00:00,not_valid_after=2028-01-09 23:59:59,hash_algorithm=sha384,key_size=2048 bytes, issuer={'countryName': 'GB', 'stateOrProvinceName': 'Greater Manchester', 'localityName': 'Salford', 'organizationName': 'COMODO CA Limited', 'commonName': 'COMODO RSA Certification Authority'} 2019-01-15 00:11:48,616,root,INFO,| written file ./bob.lumreeker@gmail.com.crt,bytes=1870,ok=True
Pour une vérification rapide, cherchez la dernière ligne – si elle indique "written file", alors tout va bien. Le reste montre le processus de contrôle DKIM et de validation du certificat.
Nous allons commencer avec cette partie, afin de la tester entièrement avant de configurer les relais pour webhooks entrants.
L'application web est incluse dans le même projet GitHub que les parties 1 à 3, donc si vous avez suivi ces parties, vous l'avez déjà. Voici les nouveaux éléments :
Programme readSMIMEsig.py – lire un email et analyser les certificats intermédiaires et utilisateurs.
Programme webapp.py – application web simple compatible Flask pour utilisation avec les SparkPost Inbound Relay Webhooks.
webapp.ini – fichier de configuration pour ce qui précède. Un fichier de config permet de transmettre facilement les mêmes valeurs aux applications en ligne de commande et web.
Vous devez vous assurer que votre hôte a le bon numéro de port TCP ouvert aux requêtes entrantes du monde extérieur afin que SparkPost puisse envoyer des messages à votre application. Si vous êtes hébergé sur AWS EC2, par exemple, vous devrez configurer le Groupe de Sécurité de votre instance.
Les instructions pour la configuration et le démarrage de l'application web sont fournies dans notre guide d'installation – c’est assez facile. Pour vérifier que votre application fonctionne et est accessible depuis le monde extérieur, vous pouvez envoyer des requêtes (vides) depuis un autre hôte en utilisant curl, par exemple :
curl -X POST https://app.trymsys.net:8855/
Vous devriez voir une réponse comme :
{"message":"Unknown Content-Type in request headers"}
C'est une bonne chose – votre application fonctionne !
Dans webapp.log sur votre hôte, vous verrez une sortie similaire à ceci :
2019-01-15 00:11:07,575,root,INFO,Request from 38.96.5.10,scheme=https,path=/ 2019-01-15 00:11:07,575,root,INFO,| len(headers)=3,len(body)=None 2019-01-15 00:11:07,575,root,INFO,| Unknown Content-Type: None
Pour vous aider à jouer avec des données réelles dans votre application immédiatement, vous pouvez importer cette requête Postman spécifique depuis le dépôt du projet. Cela simule ce que votre compte SparkPost fera, c’est-à-dire qu'il envoie un https POST contenant un email avec un certificat spécifique et valable (appartenant à un compte de test à moi) à votre application.
Vous devez simplement changer l'adresse cible dans la requête (dans le cadre gris ci-dessus) pour correspondre à votre installation. Si vous avez changé la valeur de l'token dans webapp.ini, ajustez la valeur de l'entête dans Postman pour correspondre.
Si votre application fonctionne, vous verrez une réponse "200 OK" dans Postman. Le fichier webapp.log de votre hôte contiendra une sortie comme celle-ci :
2019-01-15 00:11:48,554,root,INFO,Request from 38.96.5.10,scheme=https,path=/ 2019-01-15 00:11:48,554,root,INFO,| len(headers)=10,len(body)=14778 2019-01-15 00:11:48,555,root,INFO,| msg_from=bob.lumreeker@gmail.com,rcpt_to=secureme@inbound.thetucks.com,len(email_rfc822)=9223 2019-01-15 00:11:48,599,root,INFO,| from=bob.lumreeker@gmail.com,DKIM passed 2019-01-15 00:11:48,600,root,INFO,| content-type=multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010908020707040304020406",content-description=None 2019-01-15 00:11:48,600,root,INFO,| content-type=text/plain; charset=utf-8; format=flowed,content-description=None 2019-01-15 00:11:48,600,root,INFO,| content-type=application/pkcs7-signature; name="smime.p7s",content-description=S/MIME Cryptographic Signature 2019-01-15 00:11:48,600,root,INFO,| filename=smime.p7s,bytes=3998 2019-01-15 00:11:48,601,root,INFO,| Certificate: subject email_address=['bob.lumreeker@gmail.com'],not_valid_before=2018-10-03 00:00:00,not_valid_after=2019-10-03 23:59:59,hash_algorithm=sha256,key_size=2048 bytes, issuer={'countryName': 'GB', 'stateOrProvinceName': 'Greater Manchester', 'localityName': 'Salford', 'organizationName': 'COMODO CA Limited', 'commonName': 'COMODO RSA Client Authentication and Secure Email CA'} 2019-01-15 00:11:48,602,root,INFO,| Certificate: subject email_address=[],not_valid_before=2013-01-10 00:00:00,not_valid_after=2028-01-09 23:59:59,hash_algorithm=sha384,key_size=2048 bytes, issuer={'countryName': 'GB', 'stateOrProvinceName': 'Greater Manchester', 'localityName': 'Salford', 'organizationName': 'COMODO CA Limited', 'commonName': 'COMODO RSA Certification Authority'} 2019-01-15 00:11:48,616,root,INFO,| written file ./bob.lumreeker@gmail.com.crt,bytes=1870,ok=True
Pour une vérification rapide, cherchez la dernière ligne – si elle indique "written file", alors tout va bien. Le reste montre le processus de contrôle DKIM et de validation du certificat.
3. Configuration des webhooks de relais entrant SparkPost
Tout d'abord, nous sélectionnons un domaine à utiliser comme notre adresse de message entrant – ici, ce sera inbound.thetucks.com. Configurez votre domaine en suivant ce guide. Voici les étapes que j'ai utilisées en détail :
3.1 Ajouter des enregistrements MX
Vous aurez besoin d'accéder à votre compte de fournisseur de services Internet spécifique. Une fois terminé, vous pouvez les vérifier avec dig – voici la commande pour mon domaine.
dig +short MX inbound.thetucks.com
Vous devriez voir :
10 rx3.sparkpostmail.com. 10 rx1.sparkpostmail.com. 10 rx2.sparkpostmail.com
3.2 Créer un domaine entrant
Utilisez la collection Postman API de SparkPost, en sélectionnant l'appel Inbound Domains / Create. Le corps de la requête POST contient votre domaine, par exemple :
{ "domain": "inbound.thetucks.com" }
3.3 Créer un Webhook de Relais
Créez un webhook de relais entrant en utilisant l'appel Postman pertinent. Le corps du message dans mon cas contient :
{ "name": "Certificate Collection Webhook", "target": "https://app.trymsys.net:8855/", "auth_token": "t0p s3cr3t t0k3n", "match": { "protocol": "SMTP", "domain": "inbound.thetucks.com" } }
Comme mentionné précédemment, je recommande de définir un auth_token à votre propre valeur secrète, comme défini dans le fichier webapp.ini sur votre hôte.
Votre valeur "target" doit correspondre à votre adresse hôte et au port TCP où vous hébergerez l'application web.
Votre valeur "domain" doit correspondre à vos enregistrements MX configurés à l'étape 1.
C’est tout ! La plomberie est terminée. Vous devriez maintenant être en mesure d'envoyer des certificats à votre adresse entrant, ils seront traités et apparaîtront sur votre hôte d'application web – dans ce cas, un fichier nommé bob.lumreeker@gmail.com.crt.
Vous pouvez maintenant envoyer des e-mails cryptés à Bob, en utilisant les outils décrits dans les parties 2 & 3 de cette série.
Vous pouvez examiner le contenu d'un certificat en utilisant :
openssl x509 -inform PEM -in bob.lumreeker\@gmail.com.crt -text -noout
Tout d'abord, nous sélectionnons un domaine à utiliser comme notre adresse de message entrant – ici, ce sera inbound.thetucks.com. Configurez votre domaine en suivant ce guide. Voici les étapes que j'ai utilisées en détail :
3.1 Ajouter des enregistrements MX
Vous aurez besoin d'accéder à votre compte de fournisseur de services Internet spécifique. Une fois terminé, vous pouvez les vérifier avec dig – voici la commande pour mon domaine.
dig +short MX inbound.thetucks.com
Vous devriez voir :
10 rx3.sparkpostmail.com. 10 rx1.sparkpostmail.com. 10 rx2.sparkpostmail.com
3.2 Créer un domaine entrant
Utilisez la collection Postman API de SparkPost, en sélectionnant l'appel Inbound Domains / Create. Le corps de la requête POST contient votre domaine, par exemple :
{ "domain": "inbound.thetucks.com" }
3.3 Créer un Webhook de Relais
Créez un webhook de relais entrant en utilisant l'appel Postman pertinent. Le corps du message dans mon cas contient :
{ "name": "Certificate Collection Webhook", "target": "https://app.trymsys.net:8855/", "auth_token": "t0p s3cr3t t0k3n", "match": { "protocol": "SMTP", "domain": "inbound.thetucks.com" } }
Comme mentionné précédemment, je recommande de définir un auth_token à votre propre valeur secrète, comme défini dans le fichier webapp.ini sur votre hôte.
Votre valeur "target" doit correspondre à votre adresse hôte et au port TCP où vous hébergerez l'application web.
Votre valeur "domain" doit correspondre à vos enregistrements MX configurés à l'étape 1.
C’est tout ! La plomberie est terminée. Vous devriez maintenant être en mesure d'envoyer des certificats à votre adresse entrant, ils seront traités et apparaîtront sur votre hôte d'application web – dans ce cas, un fichier nommé bob.lumreeker@gmail.com.crt.
Vous pouvez maintenant envoyer des e-mails cryptés à Bob, en utilisant les outils décrits dans les parties 2 & 3 de cette série.
Vous pouvez examiner le contenu d'un certificat en utilisant :
openssl x509 -inform PEM -in bob.lumreeker\@gmail.com.crt -text -noout
Tout d'abord, nous sélectionnons un domaine à utiliser comme notre adresse de message entrant – ici, ce sera inbound.thetucks.com. Configurez votre domaine en suivant ce guide. Voici les étapes que j'ai utilisées en détail :
3.1 Ajouter des enregistrements MX
Vous aurez besoin d'accéder à votre compte de fournisseur de services Internet spécifique. Une fois terminé, vous pouvez les vérifier avec dig – voici la commande pour mon domaine.
dig +short MX inbound.thetucks.com
Vous devriez voir :
10 rx3.sparkpostmail.com. 10 rx1.sparkpostmail.com. 10 rx2.sparkpostmail.com
3.2 Créer un domaine entrant
Utilisez la collection Postman API de SparkPost, en sélectionnant l'appel Inbound Domains / Create. Le corps de la requête POST contient votre domaine, par exemple :
{ "domain": "inbound.thetucks.com" }
3.3 Créer un Webhook de Relais
Créez un webhook de relais entrant en utilisant l'appel Postman pertinent. Le corps du message dans mon cas contient :
{ "name": "Certificate Collection Webhook", "target": "https://app.trymsys.net:8855/", "auth_token": "t0p s3cr3t t0k3n", "match": { "protocol": "SMTP", "domain": "inbound.thetucks.com" } }
Comme mentionné précédemment, je recommande de définir un auth_token à votre propre valeur secrète, comme défini dans le fichier webapp.ini sur votre hôte.
Votre valeur "target" doit correspondre à votre adresse hôte et au port TCP où vous hébergerez l'application web.
Votre valeur "domain" doit correspondre à vos enregistrements MX configurés à l'étape 1.
C’est tout ! La plomberie est terminée. Vous devriez maintenant être en mesure d'envoyer des certificats à votre adresse entrant, ils seront traités et apparaîtront sur votre hôte d'application web – dans ce cas, un fichier nommé bob.lumreeker@gmail.com.crt.
Vous pouvez maintenant envoyer des e-mails cryptés à Bob, en utilisant les outils décrits dans les parties 2 & 3 de cette série.
Vous pouvez examiner le contenu d'un certificat en utilisant :
openssl x509 -inform PEM -in bob.lumreeker\@gmail.com.crt -text -noout
4. Internes : vérification DKIM, validation de certificat
L'application vérifie que les e-mails reçus ont un DKIM valide et vérifie que les certificats eux-mêmes sont valides, comme décrit ici. Il y a également des notes de mise en œuvre et des idées pour des travaux ultérieurs.
L'application vérifie que les e-mails reçus ont un DKIM valide et vérifie que les certificats eux-mêmes sont valides, comme décrit ici. Il y a également des notes de mise en œuvre et des idées pour des travaux ultérieurs.
L'application vérifie que les e-mails reçus ont un DKIM valide et vérifie que les certificats eux-mêmes sont valides, comme décrit ici. Il y a également des notes de mise en œuvre et des idées pour des travaux ultérieurs.
En résumé…
Nous avons vu comment les clés publiques des destinataires peuvent être facilement rassemblées en utilisant un email vers une adresse de relais webhooks entrant. Une fois cela fait, ces destinataires peuvent recevoir leurs messages sous forme chiffrée S/MIME.
C'est tout pour le moment ! Bon envoi.
Nous avons vu comment les clés publiques des destinataires peuvent être facilement rassemblées en utilisant un email vers une adresse de relais webhooks entrant. Une fois cela fait, ces destinataires peuvent recevoir leurs messages sous forme chiffrée S/MIME.
C'est tout pour le moment ! Bon envoi.
Nous avons vu comment les clés publiques des destinataires peuvent être facilement rassemblées en utilisant un email vers une adresse de relais webhooks entrant. Une fois cela fait, ces destinataires peuvent recevoir leurs messages sous forme chiffrée S/MIME.
C'est tout pour le moment ! Bon envoi.
