Devido a vários processos, agora quase todo mundo já ouviu falar em substituição de importações. Em particular, agora o produto importado do MS Exchange está sendo substituído ativamente pelo russo genuíno sem uma única unha * Communigate Pro. Se meus colegas encontrarem tempo, acho que eles podem contar muito sobre clusters, cargas de trabalho e migração, mas quero lhe contar um sangue arrepiante, mas uma história muito menos extensa sobre os recursos nacionais de renovação de certificados neste maravilhoso produto.
Na verdade, um breve histórico. Eu tenho um pequeno laptop em um armário no qual, até recentemente, o servidor de email estava movimentado em um monte de Windows + hMailServer. Naturalmente, em virtude da substituição de importações, eu queria conhecer o Communigate Pro mais de perto, felizmente, é muito modesto em requisitos e é gratuito
em algumas escalas :
Fornecemos a versão completa do CommuniGate Pro gratuitamente para cinco usuários para fins de teste e para uso em pequenos projetos (empresas).
O conhecido pode ser iniciado
na seção Sobre nós . É bem visível lá que, em 1997, o marco "Primeira transferência" foi alcançado, os profissionais de marketing Stalker, Inc aprenderam a escrever a palavra "Release" somente em 2004, e ainda não conseguiram produzir materiais de marketing em russo para o site russo.
A instalação do produto (instalei no CentOS 7) não causou dificuldades, aproveitando a oportunidade, coloquei o CertBot lá, parafusei os certificados do Let's Encrypt e, em geral, tudo foi iniciado.
Após 3 meses, os certificados expiraram conforme o planejado e estava na hora de alterá-los.
Descobri que o Windows trouxe uma substituição muito inesperada para o cliente Telnet:
A regeneração de chaves usando as ferramentas CertBot foi chata, fiquei satisfeito, talvez, com o servidor dns1.yandex.ru, que por uma hora exibiu o desafio tac-record desatualizado ou atualizado _acme-challenge, por causa do qual eu consegui gerar certificados apenas na terceira tentativa .
E então a mágica começou.
O servidor Communigate não tem a capacidade de substituir o par de chaves por um novo por meio da interface; você deve primeiro excluir o par de chaves antigo:
Como um administrador de host localhost consciente, ativei a autenticação apenas via ssl e esqueci-a com segurança; portanto, após excluir o par de chaves, o servidor se recusou a se comunicar comigo:
Eu terminei o servidor paranóico adicionando esta linha ao arquivo /var/CommuniGate/Accounts/postmaster.macnt/account.settings:
RequireAPOP = NO;mas o sedimento, é claro, permaneceu. Naturalmente, eu queria criar um
botão para mim mesmo, o script para substituir o par de chaves por uma execução desse script em si, e não andar em círculos de acordo com as configurações do usuário.
As ferramentas de automação do Communigate estão presentes em até
quatro interfaces : comunicação de texto via conexão TCP (PWD), módulo pearl CLI.pm (CG / PL), solicitações simples da Web e XIMSS.
Por várias razões (principalmente preguiça, é claro), escolhi solicitações da Web.
Desde o início, algo deu errado:
[root@mx ~]
Como se viu, li a documentação sem atenção, tive que fazer assim:
[root@mx ~]# curl -u postmaster:password -k 'https://127.0.0.1:9100/cli/?command=getdomainsettings' {CAChain=[---];CertificateType=YES;ClientCertCA="Let's Encrypt Authority X3";ClientIPs="";DKIMenabled=YES;DKIMkey=[---DKIM];DKIMselector=dkim;DomainComment="";IPMode="All Available";PrivateSecureKey=[---];SecureCertificate=[--];TrustedCertificates=();}
Então, algo deu errado novamente:
[root@mx ~]# curl -u postmaster:password -k 'https://127.0.0.1:9100/cli/?command=getdomainsettings&domainName=test' {CAChain=[---];CertificateType=YES;ClientCertCA="Let's Encrypt Authority X3";ClientIPs="";DKIMenabled=YES;DKIMkey=[---DKIM];DKIMselector=dkim;DomainComment="";IPMode="All Available";PrivateSecureKey=[---];SecureCertificate=[--];TrustedCertificates=();}
Fiquei intrigado com essa mudança de eventos e entreguei o
suporte ao fornecedor .
Como um anúncio.
Sim, eles têm uma sala de bate-papo. E especialistas até respondem a isso. Mesmo sem nenhuma assinatura corporativa.
Como se viu, a solicitação http não entende os parâmetros nomeados. Apenas posicional, apenas incondicional:
[root@mx ~]
O domínio de teste, em total conformidade com seu nome, é um domínio de teste, portanto, não há configurações nele.
Depois, apresentei como incorporarei um certificado na URL e decidi que precisava fazer algo sobre isso. Por exemplo, use a solicitação POST de uma pessoa saudável em vez da solicitação GET do fumante para transferência de dados:
[root@mx ~]# curl -u postmaster:password -k 'https://127.0.0.1:9100/cli/' --data-urlencode 'command=getdomainsettings test' {} [root@mx ~]#
Bem, até agora tudo está indo conforme o planejado.
Vamos criptografar mantém seus tesouros no diretório /etc/letsencrypt/live/domain.my/ de lá e nós os obteremos.
Um pouco mais alto na solicitação getdomainsettings, vi que a chave privada está no campo PrivateSecureKey e, além disso, fica lá com cabeçalho e rodapé mordidos, e todo o resto é mesclado em uma linha. Vamos tentar importá-lo.
[root@mx ~]# curl -u postmaster:password -k 'https://127.0.0.1:9100/cli/' --data-urlencode "command=updatedomainsettings test {PrivateSecureKey=[`grep -v '\-\-' /etc/letsencrypt/live/domain.my/privkey.pem | tr -d '\n'`];}" <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="ru" lang="ru" dir="ltr"> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <title> domain.my</title> <link rel="stylesheet" href="/SkinFiles/domain.my/Pronto/style.css" type="text/css" /> <meta http-equiv="x-dns-prefetch-control" content="off" /> <meta name="referrer" content="no-referrer" /> </head> <body background="/SkinFiles/domain.my/Pronto/bodybgcolor.gif"> <form method="post" enctype="multipart/form-data"> <input type="hidden" name="FormCharset" value="utf-8" /> <table width="100%" border="0" cellspacing="0" cellpadding="0"> <tr><td height="25"> </td></tr> <tr valign="middle"><td align="center" bgcolor="#ffcccc" class="externalError">private key data is corrupted</td></tr> </table> </form> </body> </html> [root@mx ~]#
Bem ... eu não esperava isso.
Eu pensei que era um certbot, em vez de uma chave privada, coloquei algo estranho, retirei o conteúdo do arquivo:
[root@mx ~]# cat /etc/letsencrypt/live/domain.my/privkey.pem -----BEGIN PRIVATE KEY----- -----END PRIVATE KEY----- [root@mx ~]#
e inserido através da interface da web:
De repente, tudo correu bem:
Excluí a chave e tentei importá-la novamente com uma solicitação HTTP. Nenhum milagre aconteceu,
os dados da chave privada ainda estavam
corrompidos .
Perplexo, fui novamente visitar o
coelho do suporte técnico. O suporte técnico disse que você precisa morder o cabeçalho e rodapé do arquivo de chave privada e combinar o resultado em uma linha. Quando perguntei se fiz tudo certo com este comando:
grep -v '\-\-' /etc/letsencrypt/live/domain.my/privkey.pem | tr -d '\n'
O oficial de suporte respondeu que ele não era um especialista em grep e não sabia.
No processo de diálogo, descobri que, se eu retirar a chave antiga com a solicitação getdomainsettings, a solicitação HTTP a importa normalmente, decidi que meu grep | tr morde algo supérfluo e se despede da sala de bate-papo de Stalker.
No entanto, não foi tão simples. Depois de limpar a chave privada manualmente, descobri que ela não era importada.
Aqui eu entrei em um impasse final.
Tendo sofrido com esse fenômeno, decidi cuspir e fazer tudo manualmente, importou a chave privada pela interface da web ... E, finalmente, fiz uma solicitação de getdomainsettings. De repente, o Communigate não estava retornando para mim o que eu tinha alimentado com ele. Além disso, a chave privada Let's Encrypt após a limpeza tinha 1624 caracteres e o Communigate me mostrava apenas 1592 de comprimento.
Eu não estava pronto para essa virada e entrei no openssl. O primeiro tiro acertou o alvo:
[root@mx ~]# openssl rsa -in /etc/letsencrypt/live/domain.my/privkey.pem writing RSA key -----BEGIN RSA PRIVATE KEY----- , , -----END RSA PRIVATE KEY----- [root@mx ~]#
Viva, missão cumprida.
Não precisávamos de danças com certificados, eles apenas mordiam um cabeçalho com um rodapé e as sobras são combinadas em uma linha.
Total, o resultado final é assim para mim:
curl --user postmaster:password -k 'https://127.0.0.1:9100/cli/' --data-urlencode "command=updatedomainsettings domain.my {SecureCertificate=[`grep -v '\-\-' /etc/letsencrypt/live/domain.my/cert.pem | tr -d '\n'`];PrivateSecureKey=[`openssl rsa -in /etc/letsencrypt/live/domain.my/privkey.pem 2> /dev/null | grep -v '\-\-' | tr -d '\n'`];CAChain=[`grep -v '\-\-' /etc/letsencrypt/live/domain.my/chain.pem | tr -d '\n'`];}"
Como o unix-shell não é meu ambiente nativo, aprecio muito as otimizações.
Bem, e você nunca sabe, de repente alguém vai precisar de mim, eu não consegui pesquisar no Google.
* as unhas do Communigate Pro realmente não foram encontradas