S/MIME Parte 4: Coletando Chaves Públicas de Destinatários de Forma Simples – com Webhooks de Relé de Entrada do SparkPost
Pássaro
1 de fev. de 2019
1 min read
Principais Conclusões
Premissa: Enviar e-mail criptografado com S/MIME não é difícil uma vez que você pode coletar automaticamente a chave pública de cada destinatário. Este post fecha essa lacuna utilizando Webhooks de Relay de Entrada do SparkPost para receber e-mails assinados, extrair certificados e armazená-los para criptografia posterior.
Objetivo: Construir um serviço de webhook baseado em Flask que escute mensagens assinadas recebidas, valide-as (DKIM + verificações de certificado) e armazene com segurança cada chave pública no disco para uso em e-mails seguros enviados.
Destaques:
Problema: A troca manual de chaves não escala para e-mails gerados por aplicativos.
Solução: Convidar usuários a enviar um e-mail assinado; o webhook de entrada automaticamente analisa e armazena seu certificado PEM.
Etapas de configuração:
Configure um Domínio de Entrada e registros MX (por exemplo, inbound.seudominio.com).
Crie um Webhook de Relay de Entrada via API do SparkPost apontando para o endpoint do seu aplicativo.
Implante um pequeno aplicativo Flask (webapp.py) usando a configuração do webapp.ini.
Registre extensivamente para transparência; integre Pytest + Travis CI para validação automatizada.
Medidas de segurança:
Verifique as assinaturas DKIM e a autenticidade da mensagem.
Valide a cadeia de confiança do certificado antes de armazená-lo.
Use um token de autenticação secreto nos cabeçalhos do webhook.
Saída:
Cada mensagem de entrada válida cria um arquivo de certificado como bob.lumreeker@gmail.com.crt.
Uma vez armazenadas, essas chaves possibilitam respostas criptografadas usando scripts anteriores das partes 2 e 3.
Destaques de Perguntas e Respostas
Por que é tão crítico coletar chaves de destinatários para S/MIME?
Porque a criptografia requer a chave pública de cada destinatário; automatizar esta etapa permite que qualquer aplicativo envie e-mails seguros sem troca manual.
Como o Webhook de Relay Inbound do SparkPost simplifica a coleta de chaves?
Ele converte qualquer e-mail assinado recebido em uma carga útil JSON estruturada, permitindo que seu aplicativo analise e persista certificados programaticamente.
Quais salvaguardas evitam falsificações ou envios indesejados?
O serviço valida assinaturas DKIM, impõe tokens de autenticação e rejeita mensagens malformadas ou não assinadas.
Onde os certificados são armazenados e em qual formato?
Eles são gravados em disco no formato PEM (
.crtarquivos), prontos para uso pela ferramenta de assinatura/cripografia construída nas partes anteriores.Qual é o fluxo de trabalho do desenvolvedor?
Execute o aplicativo Flask, verifique com o Postman usando a carga útil de amostra fornecida e, em seguida, conecte-o ao webhook ao vivo do SparkPost para operação contínua.
Conclusão geral?
A gestão de chaves S/MIME pode ser totalmente automatizada com algumas linhas de Python e APIs do SparkPost—trazendo criptografia escalável para qualquer fluxo de trabalho de email gerado por aplicativo.
No parte 1, fizemos um rápido tour sobre S/MIME, olhando para a assinatura e criptografia de nossos fluxos de mensagens em uma variedade de clientes de e-mail. A parte 2 nos levou através de uma ferramenta de linha de comando simples para assinar e criptografar e-mails, e depois enviá-los através do SparkPost. A parte 3 mostrou como injetar fluxos de e-mail seguros em plataformas locais, como Port25 PowerMTA e Momentum.
Nesta série, vimos como incluir uma assinatura S/MIME é bastante simples. Enviar e-mails criptografados em S/MIME é mais complexo porque você precisa obter as chaves públicas dos destinatários. É uma coisa quando você está usando um cliente de e-mail para humanos como o Thunderbird – mas como isso pode funcionar com fluxos de e-mail gerados por aplicativos? E-mails gerados por aplicativos, como os usados por plataformas de namoro, requerem uma estratégia cuidadosa para maximizar o envolvimento. Veja como os aplicativos de namoro criam experiências de e-mail acionadas convincentes.
Mas espere – há outra maneira de entrar em Mordor para obter essas chaves. Seu serviço pode convidar seus clientes (por e-mail, é claro) a lhe enviar de volta um e-mail assinado para um endereço de atendimento ao cliente conhecido. Usando os poderes mágicos dos webhooks do SparkPost Inbound Relay, extrairemos e armazenaremos essa chave pública para você usar.
Podemos resumir isso em um caso de uso simples:
Como destinatário de mensagens, eu forneço ao seu serviço minha assinatura de e-mail pessoal via e-mail, para que no futuro, e-mails possam ser enviados para mim em forma criptografada S/MIME.
A partir disso, vamos derivar alguns requisitos mais detalhados:
Precisamos de um serviço de e-mail de entrada sempre ativo e confiável para receber esses e-mails assinados.
Não deve haver requisitos especiais quanto ao formato do e-mail, exceto que ele deve portar uma assinatura S/MIME.
Como qualquer um pode tentar enviar um e-mail para este serviço, ele deve ser projetado defensivamente, por exemplo, para rejeitar mensagens “falsificadas” de atores prejudiciais. Serão necessárias várias camadas de verificação.
Se tudo estiver OK, o serviço armazenará o certificado em um arquivo, usando o conhecido formato de e-mail melhorado em texto simples (PEM).
Existem alguns requisitos não funcionais:
Serviços de webhook máquina-a-máquina podem ser difíceis de ver apenas a partir das respostas sobre o que está acontecendo internamente. O serviço deve fornecer extensos logs em nível de aplicação legíveis por humanos. Em particular, a análise e verificação do certificado devem ser registradas.
Adicionamos casos de teste para os internos do aplicativo, usando o bom framework Pytest, e executamos esses testes automaticamente na confirmação usando a integração do Travis CI com o GitHub.
OK – vamos começar!
No parte 1, fizemos um rápido tour sobre S/MIME, olhando para a assinatura e criptografia de nossos fluxos de mensagens em uma variedade de clientes de e-mail. A parte 2 nos levou através de uma ferramenta de linha de comando simples para assinar e criptografar e-mails, e depois enviá-los através do SparkPost. A parte 3 mostrou como injetar fluxos de e-mail seguros em plataformas locais, como Port25 PowerMTA e Momentum.
Nesta série, vimos como incluir uma assinatura S/MIME é bastante simples. Enviar e-mails criptografados em S/MIME é mais complexo porque você precisa obter as chaves públicas dos destinatários. É uma coisa quando você está usando um cliente de e-mail para humanos como o Thunderbird – mas como isso pode funcionar com fluxos de e-mail gerados por aplicativos? E-mails gerados por aplicativos, como os usados por plataformas de namoro, requerem uma estratégia cuidadosa para maximizar o envolvimento. Veja como os aplicativos de namoro criam experiências de e-mail acionadas convincentes.
Mas espere – há outra maneira de entrar em Mordor para obter essas chaves. Seu serviço pode convidar seus clientes (por e-mail, é claro) a lhe enviar de volta um e-mail assinado para um endereço de atendimento ao cliente conhecido. Usando os poderes mágicos dos webhooks do SparkPost Inbound Relay, extrairemos e armazenaremos essa chave pública para você usar.
Podemos resumir isso em um caso de uso simples:
Como destinatário de mensagens, eu forneço ao seu serviço minha assinatura de e-mail pessoal via e-mail, para que no futuro, e-mails possam ser enviados para mim em forma criptografada S/MIME.
A partir disso, vamos derivar alguns requisitos mais detalhados:
Precisamos de um serviço de e-mail de entrada sempre ativo e confiável para receber esses e-mails assinados.
Não deve haver requisitos especiais quanto ao formato do e-mail, exceto que ele deve portar uma assinatura S/MIME.
Como qualquer um pode tentar enviar um e-mail para este serviço, ele deve ser projetado defensivamente, por exemplo, para rejeitar mensagens “falsificadas” de atores prejudiciais. Serão necessárias várias camadas de verificação.
Se tudo estiver OK, o serviço armazenará o certificado em um arquivo, usando o conhecido formato de e-mail melhorado em texto simples (PEM).
Existem alguns requisitos não funcionais:
Serviços de webhook máquina-a-máquina podem ser difíceis de ver apenas a partir das respostas sobre o que está acontecendo internamente. O serviço deve fornecer extensos logs em nível de aplicação legíveis por humanos. Em particular, a análise e verificação do certificado devem ser registradas.
Adicionamos casos de teste para os internos do aplicativo, usando o bom framework Pytest, e executamos esses testes automaticamente na confirmação usando a integração do Travis CI com o GitHub.
OK – vamos começar!
No parte 1, fizemos um rápido tour sobre S/MIME, olhando para a assinatura e criptografia de nossos fluxos de mensagens em uma variedade de clientes de e-mail. A parte 2 nos levou através de uma ferramenta de linha de comando simples para assinar e criptografar e-mails, e depois enviá-los através do SparkPost. A parte 3 mostrou como injetar fluxos de e-mail seguros em plataformas locais, como Port25 PowerMTA e Momentum.
Nesta série, vimos como incluir uma assinatura S/MIME é bastante simples. Enviar e-mails criptografados em S/MIME é mais complexo porque você precisa obter as chaves públicas dos destinatários. É uma coisa quando você está usando um cliente de e-mail para humanos como o Thunderbird – mas como isso pode funcionar com fluxos de e-mail gerados por aplicativos? E-mails gerados por aplicativos, como os usados por plataformas de namoro, requerem uma estratégia cuidadosa para maximizar o envolvimento. Veja como os aplicativos de namoro criam experiências de e-mail acionadas convincentes.
Mas espere – há outra maneira de entrar em Mordor para obter essas chaves. Seu serviço pode convidar seus clientes (por e-mail, é claro) a lhe enviar de volta um e-mail assinado para um endereço de atendimento ao cliente conhecido. Usando os poderes mágicos dos webhooks do SparkPost Inbound Relay, extrairemos e armazenaremos essa chave pública para você usar.
Podemos resumir isso em um caso de uso simples:
Como destinatário de mensagens, eu forneço ao seu serviço minha assinatura de e-mail pessoal via e-mail, para que no futuro, e-mails possam ser enviados para mim em forma criptografada S/MIME.
A partir disso, vamos derivar alguns requisitos mais detalhados:
Precisamos de um serviço de e-mail de entrada sempre ativo e confiável para receber esses e-mails assinados.
Não deve haver requisitos especiais quanto ao formato do e-mail, exceto que ele deve portar uma assinatura S/MIME.
Como qualquer um pode tentar enviar um e-mail para este serviço, ele deve ser projetado defensivamente, por exemplo, para rejeitar mensagens “falsificadas” de atores prejudiciais. Serão necessárias várias camadas de verificação.
Se tudo estiver OK, o serviço armazenará o certificado em um arquivo, usando o conhecido formato de e-mail melhorado em texto simples (PEM).
Existem alguns requisitos não funcionais:
Serviços de webhook máquina-a-máquina podem ser difíceis de ver apenas a partir das respostas sobre o que está acontecendo internamente. O serviço deve fornecer extensos logs em nível de aplicação legíveis por humanos. Em particular, a análise e verificação do certificado devem ser registradas.
Adicionamos casos de teste para os internos do aplicativo, usando o bom framework Pytest, e executamos esses testes automaticamente na confirmação usando a integração do Travis CI com o GitHub.
OK – vamos começar!
1. Visão geral da solução
Veja como será a solução geral.
Veja como será a solução geral.
Veja como será a solução geral.
2. Instalando, configurando e iniciando o aplicativo web
Vamos começar por esta parte, para que a tenhamos totalmente testada antes de implementar os webhooks de relé de entrada.
O aplicativo web está incluído no mesmo projeto GitHub das partes 1 – 3, então se você seguiu essas partes, já o possui. Aqui estão as novidades:
Programa readSMIMEsig.py – lê um e-mail e extrai os certificados intermediários e de usuário.
Programa webapp.py – aplicação web simples compatível com Flask para uso com os Webhooks de Relé de Entrada do SparkPost.
webapp.ini – arquivo de configuração para o acima. Um arquivo de configuração permite que os mesmos valores sejam passados facilmente para aplicações de linha de comando e web.
Você precisa garantir que seu host tenha o número da porta TCP correto aberto para solicitações de entrada do mundo exterior, para que o SparkPost possa enviar mensagens para seu aplicativo. Se você estiver hospedado no AWS EC2, por exemplo, precisará configurar o Grupo de Segurança de sua instância.
Instruções para configurar e iniciar o aplicativo web estão disponíveis em nosso guia de configuração – é bem fácil. Para verificar se seu aplicativo está em execução e acessível do mundo exterior, você pode enviar solicitações (em branco) de outro host usando curl, por exemplo:
curl -X POST https://app.trymsys.net:8855/
Você deve ver uma resposta como:
{"message":"Unknown Content-Type in request headers"}
Isso é uma boa notícia – seu aplicativo está em execução!
No webapp.log no seu host, você verá uma saída semelhante a esta:
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
Para ajudá-lo a brincar com dados reais em seu aplicativo imediatamente, você pode importar esta solicitação do Postman específica do repositório do projeto. Isso simula o que sua conta SparkPost estará fazendo, ou seja, envia um POST https contendo um e-mail com um certificado específico e válido (pertencente a uma conta de teste minha) para seu aplicativo.
Você só precisa mudar o endereço de destino na solicitação (na caixa cinza acima) para corresponder à sua instalação. Se você alterou o valor do token no webapp.ini, ajuste o valor do cabeçalho no Postman para corresponder.
Se seu aplicativo estiver funcionando, você verá uma resposta “200 OK” de volta no Postman. Seu arquivo webapp.log do host conterá uma saída como esta:
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
Para uma rápida verificação de sanidade, procure a última linha – se disser “escrito arquivo”, então você está bem. O restante disso mostra o verificação DKIM e o processo de validação do certificado.
Vamos começar por esta parte, para que a tenhamos totalmente testada antes de implementar os webhooks de relé de entrada.
O aplicativo web está incluído no mesmo projeto GitHub das partes 1 – 3, então se você seguiu essas partes, já o possui. Aqui estão as novidades:
Programa readSMIMEsig.py – lê um e-mail e extrai os certificados intermediários e de usuário.
Programa webapp.py – aplicação web simples compatível com Flask para uso com os Webhooks de Relé de Entrada do SparkPost.
webapp.ini – arquivo de configuração para o acima. Um arquivo de configuração permite que os mesmos valores sejam passados facilmente para aplicações de linha de comando e web.
Você precisa garantir que seu host tenha o número da porta TCP correto aberto para solicitações de entrada do mundo exterior, para que o SparkPost possa enviar mensagens para seu aplicativo. Se você estiver hospedado no AWS EC2, por exemplo, precisará configurar o Grupo de Segurança de sua instância.
Instruções para configurar e iniciar o aplicativo web estão disponíveis em nosso guia de configuração – é bem fácil. Para verificar se seu aplicativo está em execução e acessível do mundo exterior, você pode enviar solicitações (em branco) de outro host usando curl, por exemplo:
curl -X POST https://app.trymsys.net:8855/
Você deve ver uma resposta como:
{"message":"Unknown Content-Type in request headers"}
Isso é uma boa notícia – seu aplicativo está em execução!
No webapp.log no seu host, você verá uma saída semelhante a esta:
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
Para ajudá-lo a brincar com dados reais em seu aplicativo imediatamente, você pode importar esta solicitação do Postman específica do repositório do projeto. Isso simula o que sua conta SparkPost estará fazendo, ou seja, envia um POST https contendo um e-mail com um certificado específico e válido (pertencente a uma conta de teste minha) para seu aplicativo.
Você só precisa mudar o endereço de destino na solicitação (na caixa cinza acima) para corresponder à sua instalação. Se você alterou o valor do token no webapp.ini, ajuste o valor do cabeçalho no Postman para corresponder.
Se seu aplicativo estiver funcionando, você verá uma resposta “200 OK” de volta no Postman. Seu arquivo webapp.log do host conterá uma saída como esta:
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
Para uma rápida verificação de sanidade, procure a última linha – se disser “escrito arquivo”, então você está bem. O restante disso mostra o verificação DKIM e o processo de validação do certificado.
Vamos começar por esta parte, para que a tenhamos totalmente testada antes de implementar os webhooks de relé de entrada.
O aplicativo web está incluído no mesmo projeto GitHub das partes 1 – 3, então se você seguiu essas partes, já o possui. Aqui estão as novidades:
Programa readSMIMEsig.py – lê um e-mail e extrai os certificados intermediários e de usuário.
Programa webapp.py – aplicação web simples compatível com Flask para uso com os Webhooks de Relé de Entrada do SparkPost.
webapp.ini – arquivo de configuração para o acima. Um arquivo de configuração permite que os mesmos valores sejam passados facilmente para aplicações de linha de comando e web.
Você precisa garantir que seu host tenha o número da porta TCP correto aberto para solicitações de entrada do mundo exterior, para que o SparkPost possa enviar mensagens para seu aplicativo. Se você estiver hospedado no AWS EC2, por exemplo, precisará configurar o Grupo de Segurança de sua instância.
Instruções para configurar e iniciar o aplicativo web estão disponíveis em nosso guia de configuração – é bem fácil. Para verificar se seu aplicativo está em execução e acessível do mundo exterior, você pode enviar solicitações (em branco) de outro host usando curl, por exemplo:
curl -X POST https://app.trymsys.net:8855/
Você deve ver uma resposta como:
{"message":"Unknown Content-Type in request headers"}
Isso é uma boa notícia – seu aplicativo está em execução!
No webapp.log no seu host, você verá uma saída semelhante a esta:
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
Para ajudá-lo a brincar com dados reais em seu aplicativo imediatamente, você pode importar esta solicitação do Postman específica do repositório do projeto. Isso simula o que sua conta SparkPost estará fazendo, ou seja, envia um POST https contendo um e-mail com um certificado específico e válido (pertencente a uma conta de teste minha) para seu aplicativo.
Você só precisa mudar o endereço de destino na solicitação (na caixa cinza acima) para corresponder à sua instalação. Se você alterou o valor do token no webapp.ini, ajuste o valor do cabeçalho no Postman para corresponder.
Se seu aplicativo estiver funcionando, você verá uma resposta “200 OK” de volta no Postman. Seu arquivo webapp.log do host conterá uma saída como esta:
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
Para uma rápida verificação de sanidade, procure a última linha – se disser “escrito arquivo”, então você está bem. O restante disso mostra o verificação DKIM e o processo de validação do certificado.
3. Configuração de webhooks de retransmissão de entrada do SparkPost
Primeiro, selecionamos um domínio para usar como nosso endereço de mensagem de entrada – aqui, será inbound.thetucks.com. Configure seu domínio seguindo este guia. Aqui estão os passos que usei em detalhes:
3.1 Adicionar Registros MX
Você precisará de acesso à sua conta específica do Provedor de Serviços de Internet. Quando concluído, você pode verificá-los com dig – aqui está o comando para meu domínio.
dig +short MX inbound.thetucks.com
Você deve ver:
10 rx3.sparkpostmail.com. 10 rx1.sparkpostmail.com. 10 rx2.sparkpostmail.com
3.2 Criar um Domínio de Entrada
Use a coleção da API Postman do SparkPost, selecionando a chamada Domínios de Entrada / Criar .. O corpo da solicitação POST contém seu domínio, por exemplo:
{ "domain": "inbound.thetucks.com" }
3.3 Criar um Webhook de Relé
Crie um webhook de relé de entrada usando a chamada apropriada do Postman. O corpo da mensagem, no meu caso, contém:
{ "name": "Certificate Collection Webhook", "target": "https://app.trymsys.net:8855/", "auth_token": "t0p s3cr3t t0k3n", "match": { "protocol": "SMTP", "domain": "inbound.thetucks.com" } }
Como mencionado anteriormente, recomendo definir um auth_token para seu próprio valor secreto, conforme definido no arquivo webapp.ini no seu host.
Seu valor “target” precisa corresponder ao endereço do seu host e à porta TCP onde você estará hospedando o aplicativo da web.
Seu valor “domain” precisa corresponder aos registros MX configurados na etapa 1.
Isso é tudo! A parte de configuração está concluída. Agora você deve ser capaz de enviar certificados para seu endereço de entrada, eles serão processados e aparecerão no seu host de aplicativo da web – neste caso, um arquivo nomeado bob.lumreeker@gmail.com.crt.
Agora você pode enviar e-mails criptografados para Bob, usando as ferramentas descritas nas partes 2 & 3 desta série.
Você pode examinar o conteúdo de um certificado usando:
openssl x509 -inform PEM -in bob.lumreeker\@gmail.com.crt -text -noout
Primeiro, selecionamos um domínio para usar como nosso endereço de mensagem de entrada – aqui, será inbound.thetucks.com. Configure seu domínio seguindo este guia. Aqui estão os passos que usei em detalhes:
3.1 Adicionar Registros MX
Você precisará de acesso à sua conta específica do Provedor de Serviços de Internet. Quando concluído, você pode verificá-los com dig – aqui está o comando para meu domínio.
dig +short MX inbound.thetucks.com
Você deve ver:
10 rx3.sparkpostmail.com. 10 rx1.sparkpostmail.com. 10 rx2.sparkpostmail.com
3.2 Criar um Domínio de Entrada
Use a coleção da API Postman do SparkPost, selecionando a chamada Domínios de Entrada / Criar .. O corpo da solicitação POST contém seu domínio, por exemplo:
{ "domain": "inbound.thetucks.com" }
3.3 Criar um Webhook de Relé
Crie um webhook de relé de entrada usando a chamada apropriada do Postman. O corpo da mensagem, no meu caso, contém:
{ "name": "Certificate Collection Webhook", "target": "https://app.trymsys.net:8855/", "auth_token": "t0p s3cr3t t0k3n", "match": { "protocol": "SMTP", "domain": "inbound.thetucks.com" } }
Como mencionado anteriormente, recomendo definir um auth_token para seu próprio valor secreto, conforme definido no arquivo webapp.ini no seu host.
Seu valor “target” precisa corresponder ao endereço do seu host e à porta TCP onde você estará hospedando o aplicativo da web.
Seu valor “domain” precisa corresponder aos registros MX configurados na etapa 1.
Isso é tudo! A parte de configuração está concluída. Agora você deve ser capaz de enviar certificados para seu endereço de entrada, eles serão processados e aparecerão no seu host de aplicativo da web – neste caso, um arquivo nomeado bob.lumreeker@gmail.com.crt.
Agora você pode enviar e-mails criptografados para Bob, usando as ferramentas descritas nas partes 2 & 3 desta série.
Você pode examinar o conteúdo de um certificado usando:
openssl x509 -inform PEM -in bob.lumreeker\@gmail.com.crt -text -noout
Primeiro, selecionamos um domínio para usar como nosso endereço de mensagem de entrada – aqui, será inbound.thetucks.com. Configure seu domínio seguindo este guia. Aqui estão os passos que usei em detalhes:
3.1 Adicionar Registros MX
Você precisará de acesso à sua conta específica do Provedor de Serviços de Internet. Quando concluído, você pode verificá-los com dig – aqui está o comando para meu domínio.
dig +short MX inbound.thetucks.com
Você deve ver:
10 rx3.sparkpostmail.com. 10 rx1.sparkpostmail.com. 10 rx2.sparkpostmail.com
3.2 Criar um Domínio de Entrada
Use a coleção da API Postman do SparkPost, selecionando a chamada Domínios de Entrada / Criar .. O corpo da solicitação POST contém seu domínio, por exemplo:
{ "domain": "inbound.thetucks.com" }
3.3 Criar um Webhook de Relé
Crie um webhook de relé de entrada usando a chamada apropriada do Postman. O corpo da mensagem, no meu caso, contém:
{ "name": "Certificate Collection Webhook", "target": "https://app.trymsys.net:8855/", "auth_token": "t0p s3cr3t t0k3n", "match": { "protocol": "SMTP", "domain": "inbound.thetucks.com" } }
Como mencionado anteriormente, recomendo definir um auth_token para seu próprio valor secreto, conforme definido no arquivo webapp.ini no seu host.
Seu valor “target” precisa corresponder ao endereço do seu host e à porta TCP onde você estará hospedando o aplicativo da web.
Seu valor “domain” precisa corresponder aos registros MX configurados na etapa 1.
Isso é tudo! A parte de configuração está concluída. Agora você deve ser capaz de enviar certificados para seu endereço de entrada, eles serão processados e aparecerão no seu host de aplicativo da web – neste caso, um arquivo nomeado bob.lumreeker@gmail.com.crt.
Agora você pode enviar e-mails criptografados para Bob, usando as ferramentas descritas nas partes 2 & 3 desta série.
Você pode examinar o conteúdo de um certificado usando:
openssl x509 -inform PEM -in bob.lumreeker\@gmail.com.crt -text -noout
4. Internos: verificação DKIM, validação de certificado
O aplicativo verifica se os e-mails recebidos têm DKIM válidos e verifica se os próprios certificados são válidos, conforme descrito aqui. Há notas de implementação lá também, e ideias para trabalhos futuros.
O aplicativo verifica se os e-mails recebidos têm DKIM válidos e verifica se os próprios certificados são válidos, conforme descrito aqui. Há notas de implementação lá também, e ideias para trabalhos futuros.
O aplicativo verifica se os e-mails recebidos têm DKIM válidos e verifica se os próprios certificados são válidos, conforme descrito aqui. Há notas de implementação lá também, e ideias para trabalhos futuros.
Resumindo...
Vimos como chaves públicas de destinatários podem ser facilmente coletadas usando um e-mail para um endereço de webhook de relay de entrada. Uma vez feito isso, esses destinatários podem receber suas mensagens na forma criptografada S/MIME.
É isso por enquanto! Boas envios.
Vimos como chaves públicas de destinatários podem ser facilmente coletadas usando um e-mail para um endereço de webhook de relay de entrada. Uma vez feito isso, esses destinatários podem receber suas mensagens na forma criptografada S/MIME.
É isso por enquanto! Boas envios.
Vimos como chaves públicas de destinatários podem ser facilmente coletadas usando um e-mail para um endereço de webhook de relay de entrada. Uma vez feito isso, esses destinatários podem receber suas mensagens na forma criptografada S/MIME.
É isso por enquanto! Boas envios.
