S/MIME Część 4: Łatwe zbieranie kluczy publicznych odbiorców – z webhookami SparkPost Inbound Relay
Ptak
1 lut 2019
1 min read
Kluczowe Wnioski
Przesłanie: Wysyłanie e-maili szyfrowanych za pomocą S/MIME nie jest trudne, gdy można automatycznie zbierać klucz publiczny każdego odbiorcy. Ten wpis wypełnia tę lukę poprzez wykorzystanie SparkPost Inbound Relay Webhooks do odbierania podpisanych e-maili, ekstrakcji certyfikatów i ich przechowywania do późniejszego szyfrowania.
Cel: Zbuduj usługę webhook opartą na Flask, która nasłuchuje przychodzących podpisanych wiadomości, weryfikuje je (sprawdzanie DKIM + certyfikatu), i bezpiecznie zapisuje każdy klucz publiczny na dysku do wykorzystania w wychodzącej bezpiecznej poczcie.
Najważniejsze cechy:
Problem: Ręczna wymiana kluczy nie skaluje się dla e-maili generowanych przez aplikacje.
Rozwiązanie: Zaproś użytkowników do wysłania podpisanego e-maila; przychodzący webhook automatycznie parsuje i przechowuje ich certyfikat PEM.
Kroki konfiguracji:
Skonfiguruj Inbound Domain i rekordy MX (np. inbound.yourdomain.com).
Utwórz Inbound Relay Webhook za pomocą SparkPost API, wskazujący na punkt końcowy twojej aplikacji.
Wdrażaj małą Flask app (webapp.py) korzystając z konfiguracji z webapp.ini.
Loguj szczegółowo dla przejrzystości; zintegrować Pytest + Travis CI dla automatycznej weryfikacji.
Środki bezpieczeństwa:
Zweryfikuj podpisy DKIM i autentyczność wiadomości.
Sprawdź łańcuch zaufania certyfikatu przed przechowywaniem.
Użyj sekretnego tokena uwierzytelniającego w nagłówkach webhook.
Wynik:
Każda ważna przychodząca wiadomość tworzy plik certyfikatu, na przykład bob.lumreeker@gmail.com.crt.
Gdy są przechowywane, te klucze umożliwiają szyfrowane odpowiedzi za pomocą wcześniejszych skryptów z części 2 i 3.
Q&A Highlights
Dlaczego zbieranie kluczy odbiorcy jest tak istotne dla S/MIME?
Ponieważ szyfrowanie wymaga klucza publicznego każdego odbiorcy; automatyzacja tego kroku pozwala każdej aplikacji wysyłać bezpieczną pocztę bez ręcznej wymiany.
Jak SparkPost Inbound Relay Webhook upraszcza zbieranie kluczowych danych?
Konwertuje każdą podpisaną wiadomość e-mail przychodzącą na ustrukturyzowany ładunek JSON, umożliwiając Twojej aplikacji analizę i przechowywanie certyfikatów programistycznie.
Jakie zabezpieczenia zapobiegają fałszowaniu lub niechcianym zgłoszeniom?
Usługa weryfikuje podpisy DKIM, wymusza tokeny uwierzytelniające i odrzuca nieprawidłowo sformułowane lub niepodpisane wiadomości.
Gdzie są przechowywane certyfikaty i w jakim formacie?
Są zapisane na dysku w formacie PEM (
.crtpliki), gotowe do użycia przez narzędzia do podpisywania/szyfrowania zbudowane we wcześniejszych częściach.Jaki jest proces pracy developera?
Uruchom aplikację Flask, zweryfikuj za pomocą Postman przy użyciu dostarczonego przykładowego ładunku, a następnie połącz ją z aktywnym webhookiem SparkPost dla ciągłej pracy.
Ogólne wnioski?
Zarządzanie kluczami S/MIME może być w pełni zautomatyzowane za pomocą kilku linii kodu w Pythonie i SparkPost APIs—wprowadzając skalowalne szyfrowanie do każdego przepływu pracy z e-maili generowanymi przez aplikacje.
W części 1, przeprowadziliśmy szybki przegląd S/MIME, przyglądając się podpisywaniu i szyfrowaniu naszych strumieni wiadomości w różnych klientach pocztowych. Część 2 przeprowadziła nas przez prostą narzędziową linię poleceń do podpisywania i szyfrowania e-maili, a następnie wysyłania ich przez SparkPost. Część 3 pokazała, jak wstrzyknąć bezpieczne strumienie poczty do platform lokalnych, takich jak Port25 PowerMTA i Momentum.
W tej serii widzieliśmy, że dołączenie podpisu S/MIME jest stosunkowo proste. Wysyłanie zaszyfrowanej poczty S/MIME jest bardziej skomplikowane, ponieważ trzeba uzyskać klucze publiczne odbiorców. To inna sprawa, gdy używasz klienta poczty dla ludzi, takiego jak Thunderbird – ale jak to działa w przypadku strumieni e-mail generowanych przez aplikacje? E-maile generowane przez aplikacje, jak te używane przez platformy randkowe, wymagają starannej strategii do maksymalizacji zaangażowania. Zobacz, jak aplikacje randkowe tworzą przyciągające uwagę uruchamiające doświadczenia e-mail.
Ale poczekaj – jest jeszcze inny sposób na dostanie się do Mordor, aby uzyskać te klucze. Twoja usługa może zaprosić Twoich klientów (oczywiście przez e-mail) do przesłania Ci podpisanej wiadomości na znany adres obsługi klienta. Używając magicznych mocy webhooków SparkPost Inbound Relay, wyciągniemy i przechowamy ten klucz publiczny do Twojego użytku.
Możemy to podsumować w prostym przypadku użycia:
Jako odbiorca wiadomości, przekazuję twojej usłudze mój osobisty podpis e-mailowy poprzez e-mail, aby w przyszłości wiadomości e-mail mogły być wysyłane do mnie w formie zaszyfrowanej S/MIME.
Na tej podstawie wywiedziemy bardziej szczegółowe wymagania:
Potrzebujemy niezawodnej, zawsze włączonej usługi przyjmowania e-maili, aby odbierać te podpisane wiadomości.
Nie powinny istnieć specjalne wymagania dotyczące formatu poczty, poza tym, że powinien on zawierać podpis S/MIME.
Ponieważ każdy może spróbować wysłać wiadomość do tej usługi, powinna ona być zaprojektowana defensywnie, na przykład aby odrzucać „podrobione” wiadomości od złych aktorów. Będzie potrzeba kilku warstw weryfikacji.
Jeśli wszystko się zgadza, usługa zapisze certyfikat w pliku, używając dobrze znanego formatu tekstowego Privacy-Enhanced Mail (PEM).
Istnieją pewne wymagania niefunkcjonalne:
Usługi webhook z maszyny do maszyny mogą być trudne do zauważenia tylko z odpowiedzi na to, co dzieje się wewnątrz. Usługa powinna zapewniać obszerne, czytelne dla człowieka logi aplikacji na poziomie aplikacji, w szczególności powinno być prowadzone logowanie weryfikacji i parsowanie certyfikatów.
Dodajemy przypadki testowe dla wewnętrznych części aplikacji, używając fajnego frameworka Pytest, a następnie automatycznie uruchamiamy te testy przy zameldowaniu używając integracji Travis CI z GitHub.
OK – zaczynamy!
W części 1, przeprowadziliśmy szybki przegląd S/MIME, przyglądając się podpisywaniu i szyfrowaniu naszych strumieni wiadomości w różnych klientach pocztowych. Część 2 przeprowadziła nas przez prostą narzędziową linię poleceń do podpisywania i szyfrowania e-maili, a następnie wysyłania ich przez SparkPost. Część 3 pokazała, jak wstrzyknąć bezpieczne strumienie poczty do platform lokalnych, takich jak Port25 PowerMTA i Momentum.
W tej serii widzieliśmy, że dołączenie podpisu S/MIME jest stosunkowo proste. Wysyłanie zaszyfrowanej poczty S/MIME jest bardziej skomplikowane, ponieważ trzeba uzyskać klucze publiczne odbiorców. To inna sprawa, gdy używasz klienta poczty dla ludzi, takiego jak Thunderbird – ale jak to działa w przypadku strumieni e-mail generowanych przez aplikacje? E-maile generowane przez aplikacje, jak te używane przez platformy randkowe, wymagają starannej strategii do maksymalizacji zaangażowania. Zobacz, jak aplikacje randkowe tworzą przyciągające uwagę uruchamiające doświadczenia e-mail.
Ale poczekaj – jest jeszcze inny sposób na dostanie się do Mordor, aby uzyskać te klucze. Twoja usługa może zaprosić Twoich klientów (oczywiście przez e-mail) do przesłania Ci podpisanej wiadomości na znany adres obsługi klienta. Używając magicznych mocy webhooków SparkPost Inbound Relay, wyciągniemy i przechowamy ten klucz publiczny do Twojego użytku.
Możemy to podsumować w prostym przypadku użycia:
Jako odbiorca wiadomości, przekazuję twojej usłudze mój osobisty podpis e-mailowy poprzez e-mail, aby w przyszłości wiadomości e-mail mogły być wysyłane do mnie w formie zaszyfrowanej S/MIME.
Na tej podstawie wywiedziemy bardziej szczegółowe wymagania:
Potrzebujemy niezawodnej, zawsze włączonej usługi przyjmowania e-maili, aby odbierać te podpisane wiadomości.
Nie powinny istnieć specjalne wymagania dotyczące formatu poczty, poza tym, że powinien on zawierać podpis S/MIME.
Ponieważ każdy może spróbować wysłać wiadomość do tej usługi, powinna ona być zaprojektowana defensywnie, na przykład aby odrzucać „podrobione” wiadomości od złych aktorów. Będzie potrzeba kilku warstw weryfikacji.
Jeśli wszystko się zgadza, usługa zapisze certyfikat w pliku, używając dobrze znanego formatu tekstowego Privacy-Enhanced Mail (PEM).
Istnieją pewne wymagania niefunkcjonalne:
Usługi webhook z maszyny do maszyny mogą być trudne do zauważenia tylko z odpowiedzi na to, co dzieje się wewnątrz. Usługa powinna zapewniać obszerne, czytelne dla człowieka logi aplikacji na poziomie aplikacji, w szczególności powinno być prowadzone logowanie weryfikacji i parsowanie certyfikatów.
Dodajemy przypadki testowe dla wewnętrznych części aplikacji, używając fajnego frameworka Pytest, a następnie automatycznie uruchamiamy te testy przy zameldowaniu używając integracji Travis CI z GitHub.
OK – zaczynamy!
W części 1, przeprowadziliśmy szybki przegląd S/MIME, przyglądając się podpisywaniu i szyfrowaniu naszych strumieni wiadomości w różnych klientach pocztowych. Część 2 przeprowadziła nas przez prostą narzędziową linię poleceń do podpisywania i szyfrowania e-maili, a następnie wysyłania ich przez SparkPost. Część 3 pokazała, jak wstrzyknąć bezpieczne strumienie poczty do platform lokalnych, takich jak Port25 PowerMTA i Momentum.
W tej serii widzieliśmy, że dołączenie podpisu S/MIME jest stosunkowo proste. Wysyłanie zaszyfrowanej poczty S/MIME jest bardziej skomplikowane, ponieważ trzeba uzyskać klucze publiczne odbiorców. To inna sprawa, gdy używasz klienta poczty dla ludzi, takiego jak Thunderbird – ale jak to działa w przypadku strumieni e-mail generowanych przez aplikacje? E-maile generowane przez aplikacje, jak te używane przez platformy randkowe, wymagają starannej strategii do maksymalizacji zaangażowania. Zobacz, jak aplikacje randkowe tworzą przyciągające uwagę uruchamiające doświadczenia e-mail.
Ale poczekaj – jest jeszcze inny sposób na dostanie się do Mordor, aby uzyskać te klucze. Twoja usługa może zaprosić Twoich klientów (oczywiście przez e-mail) do przesłania Ci podpisanej wiadomości na znany adres obsługi klienta. Używając magicznych mocy webhooków SparkPost Inbound Relay, wyciągniemy i przechowamy ten klucz publiczny do Twojego użytku.
Możemy to podsumować w prostym przypadku użycia:
Jako odbiorca wiadomości, przekazuję twojej usłudze mój osobisty podpis e-mailowy poprzez e-mail, aby w przyszłości wiadomości e-mail mogły być wysyłane do mnie w formie zaszyfrowanej S/MIME.
Na tej podstawie wywiedziemy bardziej szczegółowe wymagania:
Potrzebujemy niezawodnej, zawsze włączonej usługi przyjmowania e-maili, aby odbierać te podpisane wiadomości.
Nie powinny istnieć specjalne wymagania dotyczące formatu poczty, poza tym, że powinien on zawierać podpis S/MIME.
Ponieważ każdy może spróbować wysłać wiadomość do tej usługi, powinna ona być zaprojektowana defensywnie, na przykład aby odrzucać „podrobione” wiadomości od złych aktorów. Będzie potrzeba kilku warstw weryfikacji.
Jeśli wszystko się zgadza, usługa zapisze certyfikat w pliku, używając dobrze znanego formatu tekstowego Privacy-Enhanced Mail (PEM).
Istnieją pewne wymagania niefunkcjonalne:
Usługi webhook z maszyny do maszyny mogą być trudne do zauważenia tylko z odpowiedzi na to, co dzieje się wewnątrz. Usługa powinna zapewniać obszerne, czytelne dla człowieka logi aplikacji na poziomie aplikacji, w szczególności powinno być prowadzone logowanie weryfikacji i parsowanie certyfikatów.
Dodajemy przypadki testowe dla wewnętrznych części aplikacji, używając fajnego frameworka Pytest, a następnie automatycznie uruchamiamy te testy przy zameldowaniu używając integracji Travis CI z GitHub.
OK – zaczynamy!
1. Przegląd rozwiązania
Oto, jak będzie wyglądać ogólne rozwiązanie.
Oto, jak będzie wyglądać ogólne rozwiązanie.
Oto, jak będzie wyglądać ogólne rozwiązanie.
2. Instalowanie, konfigurowanie i uruchamianie aplikacji webowej
Zaczniemy od tej części, abyśmy mieli ją w pełni przetestowaną przed podłączeniem webhooków z przychodzącym przekaźnikiem.
Aplikacja webowa jest zawarta w tym samym projekcie GitHub co części 1 – 3, więc jeśli śledziłeś te części, już ją masz. Oto nowe elementy:
Program readSMIMEsig.py – przeczytaj email i wyodrębnij certyfikaty pośrednie i użytkownika.
Program webapp.py – prosta aplikacja webowa kompatybilna z Flask do użycia z SparkPost Inbound Relay Webhooks.
webapp.ini – plik konfiguracyjny dla powyższego. Plik konfiguracyjny umożliwia łatwe przekazywanie tych samych wartości zarówno do aplikacji wiersza poleceń, jak i aplikacji webowej.
Musisz upewnić się, że Twój host ma poprawny numer portu TCP otwarty dla przychodzących żądań z zewnątrz, aby SparkPost mógł POSTować wiadomości do Twojej aplikacji. Jeśli jesteś hostowany na AWS EC2, na przykład, będziesz musiał skonfigurować Security Group swojej instancji.
Instrukcje dotyczące konfiguracji i uruchamiania aplikacji webowej są dostarczone w naszym przewodniku instalacji – to całkiem proste. Aby sprawdzić, czy Twoja aplikacja działa i jest dostępna z zewnątrz, możesz wysłać (puste) żądania z innego hosta używając curl, na przykład:
curl -X POST https://app.trymsys.net:8855/
Powinieneś zobaczyć odpowiedź taką jak:
{"message":"Unknown Content-Type in request headers"}
To dobry znak – Twoja aplikacja działa!
W webapp.log na Twoim hostie, zobaczysz wyjście podobne do tego:
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
Aby pomóc Ci bawić się rzeczywistymi danymi w Twojej aplikacji od razu, możesz zaimportować tę konkretną żądanie Postman z repozytorium projektu. Symuluje to, co będzie robić Twoje konto SparkPost, tj. wysyła POST https zawierający email z określonym, ważnym certyfikatem (należącym do mojego konta testowego) do Twojej aplikacji.
Wystarczy, że zmienisz docelowy adres w żądaniu (w szarym polu powyżej), aby dopasować go do swojej instalacji. Jeśli zmieniłeś wartość tokenu w webapp.ini, dostosuj wartość nagłówka w Postmanie, aby pasowały do siebie.
Jeśli Twoja aplikacja działa, zobaczysz odpowiedź „200 OK” z powrotem w Postmanie. Plik webapp.log Twojego hosta zawierać będzie wyjście podobne do tego:
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
For a quick sanity check, look for the last line – if it says “written file”, then you’re good. Reszta pokazuje proces kontroli DKIM i weryfikacji certyfikatu.
Zaczniemy od tej części, abyśmy mieli ją w pełni przetestowaną przed podłączeniem webhooków z przychodzącym przekaźnikiem.
Aplikacja webowa jest zawarta w tym samym projekcie GitHub co części 1 – 3, więc jeśli śledziłeś te części, już ją masz. Oto nowe elementy:
Program readSMIMEsig.py – przeczytaj email i wyodrębnij certyfikaty pośrednie i użytkownika.
Program webapp.py – prosta aplikacja webowa kompatybilna z Flask do użycia z SparkPost Inbound Relay Webhooks.
webapp.ini – plik konfiguracyjny dla powyższego. Plik konfiguracyjny umożliwia łatwe przekazywanie tych samych wartości zarówno do aplikacji wiersza poleceń, jak i aplikacji webowej.
Musisz upewnić się, że Twój host ma poprawny numer portu TCP otwarty dla przychodzących żądań z zewnątrz, aby SparkPost mógł POSTować wiadomości do Twojej aplikacji. Jeśli jesteś hostowany na AWS EC2, na przykład, będziesz musiał skonfigurować Security Group swojej instancji.
Instrukcje dotyczące konfiguracji i uruchamiania aplikacji webowej są dostarczone w naszym przewodniku instalacji – to całkiem proste. Aby sprawdzić, czy Twoja aplikacja działa i jest dostępna z zewnątrz, możesz wysłać (puste) żądania z innego hosta używając curl, na przykład:
curl -X POST https://app.trymsys.net:8855/
Powinieneś zobaczyć odpowiedź taką jak:
{"message":"Unknown Content-Type in request headers"}
To dobry znak – Twoja aplikacja działa!
W webapp.log na Twoim hostie, zobaczysz wyjście podobne do tego:
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
Aby pomóc Ci bawić się rzeczywistymi danymi w Twojej aplikacji od razu, możesz zaimportować tę konkretną żądanie Postman z repozytorium projektu. Symuluje to, co będzie robić Twoje konto SparkPost, tj. wysyła POST https zawierający email z określonym, ważnym certyfikatem (należącym do mojego konta testowego) do Twojej aplikacji.
Wystarczy, że zmienisz docelowy adres w żądaniu (w szarym polu powyżej), aby dopasować go do swojej instalacji. Jeśli zmieniłeś wartość tokenu w webapp.ini, dostosuj wartość nagłówka w Postmanie, aby pasowały do siebie.
Jeśli Twoja aplikacja działa, zobaczysz odpowiedź „200 OK” z powrotem w Postmanie. Plik webapp.log Twojego hosta zawierać będzie wyjście podobne do tego:
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
For a quick sanity check, look for the last line – if it says “written file”, then you’re good. Reszta pokazuje proces kontroli DKIM i weryfikacji certyfikatu.
Zaczniemy od tej części, abyśmy mieli ją w pełni przetestowaną przed podłączeniem webhooków z przychodzącym przekaźnikiem.
Aplikacja webowa jest zawarta w tym samym projekcie GitHub co części 1 – 3, więc jeśli śledziłeś te części, już ją masz. Oto nowe elementy:
Program readSMIMEsig.py – przeczytaj email i wyodrębnij certyfikaty pośrednie i użytkownika.
Program webapp.py – prosta aplikacja webowa kompatybilna z Flask do użycia z SparkPost Inbound Relay Webhooks.
webapp.ini – plik konfiguracyjny dla powyższego. Plik konfiguracyjny umożliwia łatwe przekazywanie tych samych wartości zarówno do aplikacji wiersza poleceń, jak i aplikacji webowej.
Musisz upewnić się, że Twój host ma poprawny numer portu TCP otwarty dla przychodzących żądań z zewnątrz, aby SparkPost mógł POSTować wiadomości do Twojej aplikacji. Jeśli jesteś hostowany na AWS EC2, na przykład, będziesz musiał skonfigurować Security Group swojej instancji.
Instrukcje dotyczące konfiguracji i uruchamiania aplikacji webowej są dostarczone w naszym przewodniku instalacji – to całkiem proste. Aby sprawdzić, czy Twoja aplikacja działa i jest dostępna z zewnątrz, możesz wysłać (puste) żądania z innego hosta używając curl, na przykład:
curl -X POST https://app.trymsys.net:8855/
Powinieneś zobaczyć odpowiedź taką jak:
{"message":"Unknown Content-Type in request headers"}
To dobry znak – Twoja aplikacja działa!
W webapp.log na Twoim hostie, zobaczysz wyjście podobne do tego:
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
Aby pomóc Ci bawić się rzeczywistymi danymi w Twojej aplikacji od razu, możesz zaimportować tę konkretną żądanie Postman z repozytorium projektu. Symuluje to, co będzie robić Twoje konto SparkPost, tj. wysyła POST https zawierający email z określonym, ważnym certyfikatem (należącym do mojego konta testowego) do Twojej aplikacji.
Wystarczy, że zmienisz docelowy adres w żądaniu (w szarym polu powyżej), aby dopasować go do swojej instalacji. Jeśli zmieniłeś wartość tokenu w webapp.ini, dostosuj wartość nagłówka w Postmanie, aby pasowały do siebie.
Jeśli Twoja aplikacja działa, zobaczysz odpowiedź „200 OK” z powrotem w Postmanie. Plik webapp.log Twojego hosta zawierać będzie wyjście podobne do tego:
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
For a quick sanity check, look for the last line – if it says “written file”, then you’re good. Reszta pokazuje proces kontroli DKIM i weryfikacji certyfikatu.
3. Konfiguracja webhooków przychodzących SparkPost
Najpierw wybieramy domenę, która będzie służyć jako nasz adres wiadomości przychodzących – tutaj będzie to inbound.thetucks.com. Skonfiguruj swoją domenę zgodnie z tym przewodnikiem. Oto kroki, których użyłem w szczegółach:
3.1 Dodaj rekordy MX
Będziesz potrzebować dostępu do swojego konta dostawcy usług internetowych. Kiedy to zrobisz, możesz sprawdzić je za pomocą dig – oto polecenie dla mojej domeny.
dig +short MX inbound.thetucks.com
Powinieneś zobaczyć:
10 rx3.sparkpostmail.com. 10 rx1.sparkpostmail.com. 10 rx2.sparkpostmail.com
3.2 Utwórz domenę przychodzącą
Użyj kolekcji Postman API SparkPost, wybierając połączenie Inbound Domains / Create. Treść żądania POST zawiera twoją domenę, na przykład:
{ "domain": "inbound.thetucks.com" }
3.3 Utwórz Relay Webhook
Utwórz przychodzący relay webhook używając odpowiedniego połączenia Postman. Treść wiadomości w moim przypadku zawiera:
{ "name": "Certificate Collection Webhook", "target": "https://app.trymsys.net:8855/", "auth_token": "t0p s3cr3t t0k3n", "match": { "protocol": "SMTP", "domain": "inbound.thetucks.com" } }
Jak wcześniej wspomniano, zalecam ustawienie auth_token na własną, tajną wartość, zgodnie z ustawieniami w pliku webapp.ini na twoim hoście.
Twoja wartość „target” musi odpowiadać adresowi hosta i portowi TCP, na którym będziesz hostować aplikację sieciową.
Twoja wartość „domain” musi odpowiadać skonfigurowanym rekordom MX z kroku 1.
To wszystko! Instalacja zakończona. Powinieneś teraz być w stanie wysyłać certyfikaty na swój adres przychodzący, będą one przetwarzane i pojawią się na twoim hoście aplikacji sieciowej – w tym przypadku plik o nazwie bob.lumreeker@gmail.com.crt.
Teraz możesz wysyłać zaszyfrowane wiadomości e-mail do Boba, używając narzędzi opisanych w części 2 i 3 tej serii.
Możesz zbadać zawartość certyfikatu za pomocą:
openssl x509 -inform PEM -in bob.lumreeker\@gmail.com.crt -text -noout
Najpierw wybieramy domenę, która będzie służyć jako nasz adres wiadomości przychodzących – tutaj będzie to inbound.thetucks.com. Skonfiguruj swoją domenę zgodnie z tym przewodnikiem. Oto kroki, których użyłem w szczegółach:
3.1 Dodaj rekordy MX
Będziesz potrzebować dostępu do swojego konta dostawcy usług internetowych. Kiedy to zrobisz, możesz sprawdzić je za pomocą dig – oto polecenie dla mojej domeny.
dig +short MX inbound.thetucks.com
Powinieneś zobaczyć:
10 rx3.sparkpostmail.com. 10 rx1.sparkpostmail.com. 10 rx2.sparkpostmail.com
3.2 Utwórz domenę przychodzącą
Użyj kolekcji Postman API SparkPost, wybierając połączenie Inbound Domains / Create. Treść żądania POST zawiera twoją domenę, na przykład:
{ "domain": "inbound.thetucks.com" }
3.3 Utwórz Relay Webhook
Utwórz przychodzący relay webhook używając odpowiedniego połączenia Postman. Treść wiadomości w moim przypadku zawiera:
{ "name": "Certificate Collection Webhook", "target": "https://app.trymsys.net:8855/", "auth_token": "t0p s3cr3t t0k3n", "match": { "protocol": "SMTP", "domain": "inbound.thetucks.com" } }
Jak wcześniej wspomniano, zalecam ustawienie auth_token na własną, tajną wartość, zgodnie z ustawieniami w pliku webapp.ini na twoim hoście.
Twoja wartość „target” musi odpowiadać adresowi hosta i portowi TCP, na którym będziesz hostować aplikację sieciową.
Twoja wartość „domain” musi odpowiadać skonfigurowanym rekordom MX z kroku 1.
To wszystko! Instalacja zakończona. Powinieneś teraz być w stanie wysyłać certyfikaty na swój adres przychodzący, będą one przetwarzane i pojawią się na twoim hoście aplikacji sieciowej – w tym przypadku plik o nazwie bob.lumreeker@gmail.com.crt.
Teraz możesz wysyłać zaszyfrowane wiadomości e-mail do Boba, używając narzędzi opisanych w części 2 i 3 tej serii.
Możesz zbadać zawartość certyfikatu za pomocą:
openssl x509 -inform PEM -in bob.lumreeker\@gmail.com.crt -text -noout
Najpierw wybieramy domenę, która będzie służyć jako nasz adres wiadomości przychodzących – tutaj będzie to inbound.thetucks.com. Skonfiguruj swoją domenę zgodnie z tym przewodnikiem. Oto kroki, których użyłem w szczegółach:
3.1 Dodaj rekordy MX
Będziesz potrzebować dostępu do swojego konta dostawcy usług internetowych. Kiedy to zrobisz, możesz sprawdzić je za pomocą dig – oto polecenie dla mojej domeny.
dig +short MX inbound.thetucks.com
Powinieneś zobaczyć:
10 rx3.sparkpostmail.com. 10 rx1.sparkpostmail.com. 10 rx2.sparkpostmail.com
3.2 Utwórz domenę przychodzącą
Użyj kolekcji Postman API SparkPost, wybierając połączenie Inbound Domains / Create. Treść żądania POST zawiera twoją domenę, na przykład:
{ "domain": "inbound.thetucks.com" }
3.3 Utwórz Relay Webhook
Utwórz przychodzący relay webhook używając odpowiedniego połączenia Postman. Treść wiadomości w moim przypadku zawiera:
{ "name": "Certificate Collection Webhook", "target": "https://app.trymsys.net:8855/", "auth_token": "t0p s3cr3t t0k3n", "match": { "protocol": "SMTP", "domain": "inbound.thetucks.com" } }
Jak wcześniej wspomniano, zalecam ustawienie auth_token na własną, tajną wartość, zgodnie z ustawieniami w pliku webapp.ini na twoim hoście.
Twoja wartość „target” musi odpowiadać adresowi hosta i portowi TCP, na którym będziesz hostować aplikację sieciową.
Twoja wartość „domain” musi odpowiadać skonfigurowanym rekordom MX z kroku 1.
To wszystko! Instalacja zakończona. Powinieneś teraz być w stanie wysyłać certyfikaty na swój adres przychodzący, będą one przetwarzane i pojawią się na twoim hoście aplikacji sieciowej – w tym przypadku plik o nazwie bob.lumreeker@gmail.com.crt.
Teraz możesz wysyłać zaszyfrowane wiadomości e-mail do Boba, używając narzędzi opisanych w części 2 i 3 tej serii.
Możesz zbadać zawartość certyfikatu za pomocą:
openssl x509 -inform PEM -in bob.lumreeker\@gmail.com.crt -text -noout
4. Wewnętrzne: sprawdzanie DKIM, walidacja certyfikatu
Aplikacja sprawdza, czy otrzymane e-maile mają prawidłowy DKIM oraz czy same certyfikaty są ważne, jak opisano tutaj. Znajdują się tam również uwagi dotyczące implementacji i pomysły na dalszą pracę.
Aplikacja sprawdza, czy otrzymane e-maile mają prawidłowy DKIM oraz czy same certyfikaty są ważne, jak opisano tutaj. Znajdują się tam również uwagi dotyczące implementacji i pomysły na dalszą pracę.
Aplikacja sprawdza, czy otrzymane e-maile mają prawidłowy DKIM oraz czy same certyfikaty są ważne, jak opisano tutaj. Znajdują się tam również uwagi dotyczące implementacji i pomysły na dalszą pracę.
Podsumowując…
Widzieliśmy, jak klucze publiczne odbiorców mogą być łatwo zbierane przy użyciu e-maila do adresu webhooków relay przychodzących. Po wykonaniu tej czynności, odbiorcy mogą odbierać swoje wiadomości w postaci zaszyfrowanej S/MIME.
To wszystko na teraz! Szczęśliwego wysyłania.
Widzieliśmy, jak klucze publiczne odbiorców mogą być łatwo zbierane przy użyciu e-maila do adresu webhooków relay przychodzących. Po wykonaniu tej czynności, odbiorcy mogą odbierać swoje wiadomości w postaci zaszyfrowanej S/MIME.
To wszystko na teraz! Szczęśliwego wysyłania.
Widzieliśmy, jak klucze publiczne odbiorców mogą być łatwo zbierane przy użyciu e-maila do adresu webhooków relay przychodzących. Po wykonaniu tej czynności, odbiorcy mogą odbierać swoje wiadomości w postaci zaszyfrowanej S/MIME.
To wszystko na teraz! Szczęśliwego wysyłania.
