Curl NSS + Classe certificado não funciona about sped-common

[robmachado]

1 - Usar um método de criptografia que o NSS entenda (será que resolve?)
Pode ser, mas isso existe ?
2 - Criar e usar o tal banco de dados com senha do NSS na temp (ao inves dos PEM)
Passar uma senha para a classe não irá resolver pois o problema parece ser usar qq senha
3 - Usar SOAP Nativo
Boa sorte ao tentar é uma "merda" para dizer o minimo. Pois os webservices da SEFAZ não seguem padrões estritos, são muitas alterações como por exemplo o não uso de prefixos e sulfixos
4 - A classe permite que você altere a pasta onde esses certificados serão salvos !! é só indicar a pasta que você quer usar e os PEM serão salvos nela ao invés do TMP

[robmachado]

Essa é uma boa noticia @tavinus !
O NSS sempre causou problemas o que dificultava usar CentOS ou outras distribuições derivadas do RedHat. Tanto que nunca mais nem tentei usar essas distribuições já que o Debian sempre funcionava de primeira (e eu também acho o Debian mais fácil, estável e melhor documentado).

[tavinus]

Alguns outros feedbacks...

Testei em outro servidor com Debian que tem curl com OpenSSL e realmente funcionou sem problemas, portanto acho que há poucas dúvidas de o curl + NSS ser o problema.

Vale lembrar que qualquer distro baseada em Red Hat 6 ou superior provavelmente terá o curl com NSS ao invés de OpenSSL e portanto terá problemas pra rodar a versão nova.

Notei que a chave do cert era encriptografada novamente com uma senha temporária e descobri que desligar essa funcionalidade faz tudo funcionar mesmo no curl + NSS. Tem uma flag na classe SoapBase.php pra isso, mas não achei como fazer na runtime.

Arquivo: sped-common/src/Soap/SoapBase.php
Setar: protected $encriptPrivateKey = false;

Mas ele salva a chave privada na pasta temp sem criptografia, o que não é adequado obviamente. Além disso, os arquivos não parecem ser removidos nunca e vai acumulando 3 arquivos a cada vez que usamos certs em algo.

Pelo jeito tenho que remover eu mesmo depois de usar?
EDIT: Pelo que eu vi tem uma rotina de exclusao e ela até exclui 3 arquivos, mas sempre sobram mais 3 arquivos .pem lá. Mudei a flag de tempo pra 1min e removeu os antigos, mas sempre sobram 3 arquivos lá (além dos 3 que são removidos ao matar o objeto). Ainda não sei porque sobram esses 3 e tenho certeza que ele remove os 3 que estão setados no objeto.

[tavinus]

Sobre os certificados "sobrando", eu fui procurando de onde tava vindo e notei que ele recriava os certs toda vez que tinha alguma comunicação com o webservice, mas ele só exclui os arquivos quando a classe soapBase é destruída.

Ou seja, sempre que comunica ele recria, mas somente os certs da última comunicação são excluídos.

Portando, como eu estava usando meu Tools para 2 chamadas (sefazEnviaLote + sefazConsultaRecibo), ele gerava os certs duas vezes e só excluia uma, sobrando os 3 arquivos.

Eu movi a chamada de gerar certs pro construtor da classe SoapCurl e removi da função send() e parece que resolveu o problema.

Nas buscas que eu fiz, parece que a função $this->saveTemporarilyKeyFiles(); não é usada em nenhum outro local.

Arquivo: sped-common/src/Soap/SoapCurl.php

Construtor modificado:

    public function __construct(Certificate $certificate = null, LoggerInterface $logger = null)
    {
        parent::__construct($certificate, $logger);
        $this->saveTemporarilyKeyFiles(); // ADICIONADO
    }

Trecho retirado da função send():
Veja o trecho comentado em $this->saveTemporarilyKeyFiles();

        try {
            //$this->saveTemporarilyKeyFiles(); // REMOVIDO
            $oCurl = curl_init();
            $this->setCurlProxy($oCurl);

Agora não sobram mais arquivos na pasta tmp depois da execução.
Além disso, ele consegue reutilizar os certs para várias chamadas com a mesma classe Tools instanciada.

Único problema que consigo pensar é que ele gera os arquivos sempre que instancia a classe Tools, mas ao menos pro meu uso eu sempre vou querer isso mesmo.

Esse problema afeta qualquer projeto que usa essa versão da sped-common e tem alguma relação com a issue #117 que corrigiu certs sendo removidos antes da hora.

[robmachado]

@tavinus
O cURL + NSS é uma "caca" normalmente instalados em CentOS ou derivados do RedHat, sempre causam problemas com o PHP. São usadas múltiplas versões do NSS na compilação dos módulos o que causa constantes problemas no uso dos certificados. O uso do OpenSSL é muito mais estável.
E pessoalmente eu mesmo uso apenas Debian e derivados.

[tavinus]

Eita! :(

Você parece já ter mais informações sobre o caso.
Em geral eu tendo a usar Debian também, mas é relativamente comum eu pegar máquina com derivados de RedHat (CentOS, Amazon linux, etc). Nesses casos fica complicado formatar a máquina ou refazer a VM.

Infelizmente também é praticamente inviável recompilar o curl e PHP com suporte à OpenSSL.

Se você tiver alguma idéia de como implementar criptografia na chave privada que cai na temp usando NSS eu tento fazer rodar. Por enquanto eu só "arrumei" esse lance de sobrar certificados na temp (nao sobra nada depois que roda), mas ele tá salvando a chave sem criptografia enquanto o script tá rodando.

As duas idéias que eu tinha pra tentar são:

• Usar um método de criptografia que o NSS entenda (será que resolve?)
• Criar e usar o tal banco de dados com senha do NSS na temp (ao inves dos PEM)

Sinceramente eu não sei se são idéias viáveis ainda, mas seriam meus pontos de partida. Devo voltar a tentar resolver isso em breve.

De qualquer forma, por enquanto o único workaround é desligar a crypto da chave privada da tmp mesmo. Como mencionei aqui: #141 (comment)

Edit: Você tem alguma outra idéia? Daria pra usar SOAP nativo do PHP por exemplo?

Edit2: Atualmente tem a vantagem de eu nao manter os certs em PEM sem crypto, mas a desvantagem que a chave sem crypto cai na tmp (mesmo que por alguns segundos), sendo que antes ficava numa pasta mais controlada.

[tavinus]

Pelo que eu entendi, o problema é que o NSS não consegue desencriptografar a chave privada da temp por não "entender" o algoritmo usado. Tanto que ao desligar a crypto desse arquivo, tudo passa a funcionar mesmo no NSS. Aparentemente daria pra usar RSA(e outros) ao invés de PKCS#8 e assim ambos openssl e nss conseguiriam abrir ( Link1 / Link2 )

Para transformar seria algo como (não testado):

openssl rsa -des3 -in your.key -out your.encrypted.key

openssl pkcs8 -in path/to/your/pkcs8/key -out path/to/rsa/key

Já o banco de dados do NSS é algo totalmente diferente.
Ele adiciona todos os certificados nesse banco e lê de lá de dentro pelo nome do cert.
No caso usaria pkiconsole e certutil pra lidar com esse BD do NSS.
Link1 / Link2 / Link3
Edit: A senha é do banco de dados, não dos certificados.

Edit: Pensa que quando você adiciona um certificado no Firefox, ele cai num banco de dados desses. E dali em diante você usa o cert diretamente desse BD.

Vou dar uma estudada no NSS (infelizmente).
É uma porcaria, é chato, mas preciso que rode nele.
Volto a reportar aqui o que eu descobrir.

Bom saber que posso escolher a pasta dos certs, vou usar isso!

Cheers!

[robmachado]

Vou encerrar essa issue ! Mas se você descobrir alguma coisa a mais, por favor pode reabrir. Ee tenho todo interesse em resolver esse problema com o NSS. Grande Abraço !

[AlexAlexandre]

Pessoal, eu estou passando pelo mesmo problema hoje.
Estou lendo e estudando todos os artigos disponibilizados. Porém, sigo ainda sem solução.
@tavinus, qual foi a solução que você aplicou ?

Agradeço desde já qualquer ajuda.

[robmachado]

Existem muitas possibilidades ! Vai depender de qual é realmente o SEU problema
1 - desativar a encriptação da chave privada na classe soap
$tools->soap->setEncriptPrivateKey(false);
2 - redirecionar os certificados PEM para outra pasta (não a TMP)
$tools->soap->setTemporaryFolder('/var/www/seuapp/storage/');
3 - carregar os arquivos PEM ao invés do arquivo pfx
$pubk = new NFePHP\Common\Certificate\PublicKey();
$prik = new NFePHP\Common\Certificate\PrivateKey();
$cert = new NFePHP\Common\Certificate($prik, $pubk);

[AlexAlexandre]

Obrigado por responder, amigo!
Pois é a solução que encontramos aqui na minha equipe foi substituir o cURL NSS pelo OpenSSL.
Ao que parece, funcionou aqui localmente. Estou jogando para o servidor de desenvolvimento para ver o que vai rolar.

[tavinus]

Boa tarde pessoal. Recentemente atualizei as rotinas de CTe e MDFe que usamos aqui e notei que não tive problema algum com os certificados. Ao menos no caso do MDFe eu tive que refazer quase tudo, com as classes DEV atuais do Sped-MDFe. O servidor é o mesmo que tinha dado problemas antes.

A classe Certificado é usada com certeza. Eu mesmo uso ela pra algumas coisas.

Pelo que eu pude verificar, foi o Amazon Linux que trocou o Curl+NSS por Curl+OpenSSL. Eu tinha feito update de todos os pacotes do servidor antes de migrar tbm.

Enfim, parece que as novas versões de RedHat/CentOS/AmazonLinux agora usam OpenSSL ao invés de NSS.

EDIT: A VM usa Amazon Linux 32 bits