Erro SEFAZ MT - Status de Serviço - SLL Exception

Olá Pessoal,

Estou finalizando a configuração do GRC, porém no monitor o Status de Serviço de MT (Homologação) está vermelho com o status 70.

No RTWB, no canal de comunicação de status de serviço, aparece a seguinte mensagem:

"Message processing failed. Cause: com.sap.aii.af.ra.ms.api.RecoverableException: Peer sent alert: Alert Fatal: unexpected message: iaik.security.ssl.SSLException: Peer sent alert: Alert Fatal: unexpected message"

Esse erro acontece somente com MT (Homologação). No estado de SP está tudo ok.

Alguém saberia me dizer o que pode ser?

Abs.

Daniel

SAP Managed Tags:
SAP Electronic Invoicing for Brazil (SAP Nota Fiscal Eletronica)

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

Accepted Solutions (0)

Answers (4)

Após aplicação do SP20 do PI 7.0, o comm. channel referênte a consulta da NF-e parou de funcionar. Farei o procedimento descrito e posto os resultados.

Abraço a todos,

Daniel Torres

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

Pessoal,

Fizemos muitos contatos diretos com TI da SEFAZ-MT, eles fizeram alterações no ambiente deles e, sem ter que fazer o downgrade do pacote iaik, conseguimos nos conectar com o ambiente de homologação deles (PI 7.0 SP20).

Se eles nos mandarem o que alteraram no sistema deles, posto aqui no fórum.

Abraços.

Henrique,

Fizemos upgrade de nosso PI 7.0 de teste para PI 7.1 e tivemos o mesmo problema com a SEFAZ-MT. Como solução fizemos o dowgrade da iaik_ssl.jar, e funcionou até semana passada. Agora voltou a ocorrer o mesmo problema. Você havia solicitado explicação do ENCAT sobre o problema com a SEFAZ-MT. Houve algum retorno?

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

Infelizmente nao...

Ainda estou aguardando.

O que houve semana passada que fez parar de funcionar? Vcs fizeram update do sistema?

Se sim, ele vai sobreescrever o .jar,e o processo tem q ser refeito.

Abs,

Henrique.

Henrique ,

Passo pelo mesmo problema qual foi a solução para esse problema.

Att

RONALDO DE MORAES

A solucao temporaria estah descrita na thread.

Henrique.

Ola,

Estou com o mesmo problema, segue o log da comunicação realizada no PI:

ssl_debug(3): Sending v3 client_hello message to /200.241.32.196, requesting version 3.2...

ssl_debug(3): Received alert message: Alert Fatal: unexpected message

ssl_debug(3): SSLException while handshaking: Peer sent alert: Alert Fatal: unexpected message

ssl_debug(3): Shutting down SSL layer...#

Estou utilizando o mesmo certificado para conectar com as outras "SEFAZes" e não tenho nenhum problema, enviei o problema para a SEFAZ e eles me disseram que esta tudo normal.

Alguem tem uma ideia para resolver este problema,

Atenciosamente

Marcelo Macedo

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

Marcelo,

Como vc fez para fazer este debug do SSL?

Abs.

Daniel

Daniel,

Da uma olhada no arquivo /usr/sap/<SID>/DVEBMGS<sysnro>/j2ee/cluster/server0/log/application.0.log

Atenciosamente

Marcelo Macedo

Marcelo,

Abri este arquivo, mas não encontrei o erro de SSL...

Precisa mudar o trace para debug no Visual Administrator? Se sim, sabe onde e como o fazer?

Obrigado.

Daniel Nahas

Daniel,

Entra no Visual Adminstrator -->Services --> Log Configurator --> Locations --> sap.aii.messaging

selecione para o modo Debug.

Acho interessante ligar para a SEFAZ de MT e dizer que você também esta tendo o mesmo problema.

Atenciosamente

Marcelo Macedo

Pessoal,

Analisando o LOG no Visual Administrator, me deparei com o seguinte texto:

===================================================================================

additional info failed to create an SSL socket; java.net.ConnectException: Connection refused: connect

at java.net.PlainSocketImpl.socketConnect(Native Method)

at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:305)

at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:171)

at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:158)

at java.net.Socket.connect(Socket.java:464)

at java.net.Socket.connect(Socket.java:414)

at java.net.Socket.(Unknown Source)

at com.sap.aii.messaging.net.SSLSocketFactory.createSocket(SSLSocketFactory.java:335)

at com.sap.aii.messaging.net.SSLSocketFactory.createSocket(SSLSocketFactory.java:312)

at com.sap.aii.messaging.net.HTTPClientConnection.call(HTTPClientConnection.java:465)

at com.sap.aii.messaging.net.HTTPClientConnection.post(HTTPClientConnection.java:302)

at com.sap.aii.messaging.srt.CallerServiceImpl2.call(CallerServiceImpl2.java:195)

at com.sap.aii.messaging.srt.TransportBubble.onMessage(TransportBubble.java:34)

at com.sap.aii.messaging.srt.ExtensionBubble.onMessage(ExtensionBubble.java:56)

at com.sap.aii.af.mp.soap.ejb.XISOAPAdapterBean.process(XISOAPAdapterBean.java:944)

at com.sap.aii.af.mp.module.ModuleLocalLocalObjectImpl0_3.process(ModuleLocalLocalObjectImpl0_3.java:103)

at com.sap.aii.af.mp.ejb.ModuleProcessorBean.process(ModuleProcessorBean.java:292)

at com.sap.aii.af.mp.processor.ModuleProcessorLocalLocalObjectImpl0_0.process(ModuleProcessorLocalLocalObjectImpl0_0.java:103)

at com.sap.aii.af.listener.AFWListenerBean.onMessage(AFWListenerBean.java:343)

at com.sap.aii.af.listener.AFWListenerLocalObjectImpl0_0.onMessage(AFWListenerLocalObjectImpl0_0.java:103)

at com.sap.aii.af.ra.ms.impl.ServicesImpl.deliver(ServicesImpl.java:276)

at com.sap.aii.adapter.xi.ms.XIEventHandler.onDeliver(XIEventHandler.java:1049)

at com.sap.aii.af.ra.ms.impl.core.queue.consumer.RequestConsumer.onMessage(RequestConsumer.java:118)

at com.sap.aii.af.ra.ms.impl.core.queue.Queue.run(Queue.java:917)

at com.sap.aii.af.ra.ms.runtime.MSWorkWrapper.run(MSWorkWrapper.java:56)

at com.sap.engine.core.thread.impl3.ActionObject.run(ActionObject.java:37)

at java.security.AccessController.doPrivileged(Native Method)

at com.sap.engine.core.thread.impl3.SingleThread.execute(SingleThread.java:104)

at com.sap.engine.core.thread.impl3.SingleThread.run(SingleThread.java:176)

===================================================================================

O estranho, é que estou tendo problemas apenas com SEFAZ MT.

PS: Estamos no SP12 do NFE.

Abs.

Daniel

Pessoal,

tentem abrir um chamado no componente BC-XI-CON-AFW-SEC, que eh relacionado a erros na camada de seguranca (e.g. SSL) no Adapter Framework.

Abs,

Henrique.

Pessoal,

Abri o chamado na SAP reportando o problema, com telas do monitor do GRC, da sxmb_moni, e do log do visual administrator. Vamos ver o que eles dizem.

Marcelo, qual seu e-mail? Conseguiu resolver?

Abs.

Daniel

Caros,

analisei alguns outros chamados com problemas semelhantes e creio que achei a causa.

Segue abaixo o que interpretei das mensagens.

Nos ultimos SPs do PI 7.0 (possivelmente o SPS20; creio que vc deve tê-lo aplicado, Daniel), foi incluído o suporte à versao 3.2 do protocolo SSL (TLS1.1) na biblioteca IAIK.

O padrao de handshake de SSL funciona assim: depois de iniciada o handshake e o server indicar que requer SSL, o lado client que iniciou a conexao (no caso, sempre eh o PI) envia a maior versao de SSL compativel com ele; dai o server tem que responder com algo do tipo "ok, suporto essa versao" ou "nao suporto essa versao", para o qual o client deve entao enviar a proxima versao compativel, e o server avalia novamente, até achar uma versao suportada por ambos.

Isso eh o que determina o padrao, e note que as SEFAZs que funcionam (e.g. SP e RS) seguem esse padrao.*

Já a SEFAZ MT está com um comportamento diferente: quando o PI tenta estabelecer uma conexao com SSL3.2, o servidor da SEFAZ MT, em vez de responder que nao eh compativel para tentar uma versao inferior, imediatamente jah dah uma msg de erro e fecha a conexao.* Isso causa o problema e as msgs de erro que sao observadas no trace Java do SOAP Adapter e na SXMB_MONI.

Infelizmente, nao há muita solucao do lado da aplicacao cliente, pois nao existe como forcar a versao do SSL na camada de aplicacao (o handshake eh desenhado justamente de maneira que a versao seja transparente pro usuario). A unica maneira de resolver o problema em definitivo é entrar em contato com a SEFAZ MT e solicitar que eles analisem o problema e resolvam de acordo com essas informacoes. Na verdade, eu imagino que isso deve ser uma configuracao simples no IIS/Apache (ou qq outro web server) deles com algo do tipo "close session if SSL version is not supported" ou algo assim.

Em carater de urgencia, caso vc nao consiga (e provavelmente nao vai) com que a SEFAZ MT corrija o problema em tempo habil, eh possivel obter (via chamado) o .jar referente à versao anterior da biblioteca IAIK (que suportava até o SSL3.1/TLS1.0). Vc teria que substituir a versao existente no servidor por essa, e entao o problema seria resolvido temporariamente. Note que ao aplicar qq outro Support Package, esse procedimento vai ser perdido (o .jar eh substituido novamente pelo mais novo), entao essa solucao eh apenas paliativa. A unica solucao definitiva eh resolver no lado do servidor (SEFAZ).

Abs,

Henrique.

Nos chamados, eles indicaram esse comportamento atraves de uma aplicacao web de debug de conexao SSL.

Se vc roda para a SEFAZ RS ou SP:

http://demo.iaik.tugraz.at/sslinfoservlet/servlet/iaiksslserverinfo/info?hostname=nfe.sefaz.rs.gov.b...

http://demo.iaik.tugraz.at/sslinfoservlet/servlet/iaiksslserverinfo/info?hostname=nfe.fazenda.sp.gov...

após o erro de timeout (que ocorre pq nao há envio de um payload), vc pode notar que o handshake SSL ocorre com sucesso:

(...)
Checking for TLS 1.1 support...
TLS 1.1 is NOT supported by this server.
Checking for TLS 1.0 support...
TLS 1.0 is supported by this server.
Checking for SSLv3 support...
SSLv3 is supported by this server.
Checking for SSLv2 support...
SSLv2 is supported by this server.
(...)

Já para a SEFAZ MT:

http://demo.iaik.tugraz.at/sslinfoservlet/servlet/iaiksslserverinfo/info?hostname=nfe.sefaz.mt.gov.b...

após o timeout devido à falta de payload, o que se vê é:

(...)
Checking for TLS 1.1 support...
TLS 1.1 is NOT supported by this server.
Checking for TLS 1.0 support...
TLS 1.0 is NOT supported by this server.
Checking for SSLv3 support...
SSLv3 is NOT supported by this server.
Checking for SSLv2 support...
SSLv2 is NOT supported by this server.
(...)

Dá a entender que ela respondeu que nao suporta nenhuma versao de SSL, mas na verdade acredito que seja devido ao fato de ela ter fechado a conexao de cara. Enfim, eh reflexo do problema descrito acima.

Entrei em contato com a SEFAZ MT e a resposta deles foi:

" A versão do protocolo SSL da sefaz 2.0. Conforme informações da equipe de banco de dados e necessario realizar a troca da versao para 2 para conseguir enviar uma requisição. "

Mesmo assim, já a questionei o fato de por não aceitar a nossa versão de SSL (3.2), se estão simplesmente "cortando" a conexão, ou estão nos enviando a msg de que não é suportado.

Em paralelo abri o chamado na SAP solicitando a versão anterior do .JAR da biblioteca IAIK.

Estamos no aguardo.

Obrigado.

Daniel

Daniel,

o resultado do teste acima mostra que SSLv2 tb nao era suportado.

Anyway, ainda que isso seja verdade, estao eles estao fora do padrao definido pelo Manual de Integracao.

Veja no Manual v3.00, pagina 18, secao 3.2.6. Resumo dos Padroes Tecnicos:

Protocolo Internet SSL versão 3.0, com autenticação mútua através de certificados digitais.

Ou seja, eles nao utilizam a versao definida no manual.

Acredito que seria relevante você verificar com eles.

Abs,

Henrique.

Daniel,

adicionalmente, acho que vale a pena tentar "explicar" pra eles como funciona o processo SSL/TLS.

Aqui segue um link da RFC (request for comments) que define o TLS 1.2 (latest version).

http://tools.ietf.org/html/rfc5246

No Apendice E (http://tools.ietf.org/html/rfc5246#appendix-E), ele comenta sobre a retrocompatibilidade do handshake.

E.1. Compatibility with TLS 1.0/1.1 and SSL 3.0
Since there are various versions of TLS (1.0, 1.1, 1.2, and any
future versions) and SSL (2.0 and 3.0), means are needed to negotiate
the specific protocol version to use. The TLS protocol provides a
built-in mechanism for version negotiation so as not to bother other
protocol components with the complexities of version selection.
TLS versions 1.0, 1.1, and 1.2, and SSL 3.0 are very similar, and use
compatible ClientHello messages; thus, supporting all of them is
relatively easy. Similarly, servers can easily handle clients trying
to use future versions of TLS as long as the ClientHello format
remains compatible, and the client supports the highest protocol
version available in the server.
A TLS 1.2 client who wishes to negotiate with such older servers will
send a normal TLS 1.2 ClientHello, containing { 3, 3 } (TLS 1.2) in
ClientHello.client_version. If the server does not support this
version, it will respond with a ServerHello containing an older
version number. If the client agrees to use this version, the
negotiation will proceed as appropriate for the negotiated protocol.
If the version chosen by the server is not supported by the client
(or not acceptable), the client MUST send a "protocol_version" alert
message and close the connection.
If a TLS server receives a ClientHello containing a version number
greater than the highest version supported by the server, it MUST
reply according to the highest version supported by the server.

(continua)

   A TLS server can also receive a ClientHello containing a version
   number smaller than the highest supported version.  If the server
   wishes to negotiate with old clients, it will proceed as appropriate
   for the highest version supported by the server that is not greater
   than ClientHello.client_version.  For example, if the server supports
   TLS 1.0, 1.1, and 1.2, and client_version is TLS 1.0, the server will
   proceed with a TLS 1.0 ServerHello.  If server supports (or is
   willing to use) only versions greater than client_version, it MUST
   send a "protocol_version" alert message and close the connection.
   Whenever a client already knows the highest protocol version known to
   a server (for example, when resuming a session), it SHOULD initiate
   the connection in that native protocol.
   Note: some server implementations are known to implement version
   negotiation incorrectly.  For example, there are buggy TLS 1.0
   servers that simply close the connection when the client offers a
   version newer than TLS 1.0.  Also, it is known that some servers will
   refuse the connection if any TLS extensions are included in
   ClientHello.  Interoperability with such buggy servers is a complex
   topic beyond the scope of this document, and may require multiple
   connection attempts by the client.
   Earlier versions of the TLS specification were not fully clear on
   what the record layer version number (TLSPlaintext.version) should
   contain when sending ClientHello (i.e., before it is known which
   version of the protocol will be employed).  Thus, TLS servers
   compliant with this specification MUST accept any value {03,XX} as
   the record layer version number for ClientHello.
   TLS clients that wish to negotiate with older servers MAY send any
   value {03,XX} as the record layer version number.  Typical values
   would be {03,00}, the lowest version number supported by the client,
   and the value of ClientHello.client_version.  No single value will
   guarantee interoperability with all old servers, but this is a
   complex topic beyond the scope of this document.

E é justamente assim que o PI se comporta; ele envia a maior versao suporta pelo campo clientVersion, soh que no caso aparentemente o servidor nao se comporta conforme definido no padrao.

Ainda, de acordo com a informacao que vc obteve, de que eles utilizam o SSLv2, veja o seguinte trecho da RFC:

(continua)

E.2. Compatibility with SSL 2.0
   TLS 1.2 clients that wish to support SSL 2.0 servers MUST send
   version 2.0 CLIENT-HELLO messages defined in .  The message
   MUST contain the same version number as would be used for ordinary
   ClientHello, and MUST encode the supported TLS cipher suites in the
   CIPHER-SPECS-DATA field as described below.
   Warning: The ability to send version 2.0 CLIENT-HELLO messages will
   be phased out with all due haste, since the newer ClientHello format
   provides better mechanisms for moving to newer versions and
   negotiating extensions.  TLS 1.2 clients SHOULD NOT support SSL 2.0.
   However, even TLS servers that do not support SSL 2.0 MAY accept
   version 2.0 CLIENT-HELLO messages.  The message is presented below in
   sufficient detail for TLS server implementors; the true definition is
   still assumed to be .
   For negotiation purposes, 2.0 CLIENT-HELLO is interpreted the same
   way as a ClientHello with a "null" compression method and no
   extensions.  Note that this message MUST be sent directly on the
   wire, not wrapped as a TLS record.  For the purposes of calculating
   Finished and CertificateVerify, the msg_length field is not
   considered to be a part of the handshake message.
   (...)

Eu não sei se o AFW do PI suporta SSLv2, mas de posse dessa info acima, eu chutaria que não (jah que o padrão de handshake não é compatível).

De qualquer maneira, o PI atende ao requisito de comunicacao com o SSLv3, que é o padrao definido no manual de Integracao, o qual MT nao está seguindo. Vou solicitar informações ao ENCAT de como proceder.

Abs,

Henrique.

Email enviado p/ coordenacao do ENCAT solicitando esclarecimentos e como proceder com a SEFAZ MT.

Assim que tiver um retorno, posto aqui.

Abs,

Henrique.

Pessoal,

Segundo orientação do pessoal da SAP no meu chamado e também do Henrique Pinto, instalamos a versão anterior do IAIK_SSL e está tudo ok agora.

Lembrando que esta deve ser uma solução temporária, até a SEFAZ MT arrumar a versão de conexão SSL para o padrão indicado no manual de integração e algumas outras configurações.

Obrigado pela ajuda.

Daniel

Boa tarde Henrique,

Vi o post sobre o problema com Sefaz MT, e tenho o mesmo problema, como eu coloco a IAIK_SSL na versao anterior para que o probleama seja solucionado.

No aguardo.

Jefferson Maldonado

Bom dia Jefferson,

Ao que sei o problema desta thread foi resolvido pela Sefaz MT. Você está com o mesmo problema de padding ou é erro 403 de certificado?

Atenciosamente, Fernando Da Ró

Boa tarde Daniel,

Verifique as configurações de proxy e a URL do WebService da SEFAZ, caso estejam corretas tente deletar e criar um novo communication channel.

Abraços!

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

Olá Alexandre,

As configurações de Proxy estáo Ok e a URL também (https://homologacao.sefaz.mt.gov.br/nfews/NfeStatusServico).

Fiz um teste, coloquei a URL do serviço do estado de SP e funcionou também. Porém quando volto e coloco a URL de MT, o erro volta.

Obrigado pela ajuda.

Daniel

Tente colocar o IP ao invés de homologacao.sefaz.mt.gov.br e veja se funciona.

https://200.241.32.196/nfews/NfeStatusServico

Se funcionar pode ser porque o seu PI possui um arquivo de IP com estes dados fixos. Já tive isso aqui.

At.,

Bernardo Tavares Braga

Olá Bernardo,

Fiz o que vc disse e continuo com o mesmo erro: com.sap.aii.af.ra.ms.api.DeliveryException: Peer sent alert: Alert Fatal: unexpected message

Muito obrigado pela ajuda.

Att,

Daniel

Daniel,

Fiz um teste direto do meu micro e funcionou normalmente o Status Serviço da SEFAZ MT, então podemos descartar um possível problema na SEFAZ MT, veja o XML abaixo:

<?xml version="1.0" encoding="UTF-8"?>

<retConsStatServ xmlns="http://www.portalfiscal.inf.br/nfe" versao="1.07">

<tpAmb>2</tpAmb>

<verAplic>1.10</verAplic>

<cStat>107</cStat>

<xMotivo>Servico em Operacao</xMotivo>

<cUF>51</cUF>

<dhRecbto>2010-01-19T23:15:09</dhRecbto>

<tMed>1</tMed>

</retConsStatServ>

Tente limpar o cache CPA do PI e se não funcionar DELETE e CRIE um novo communication channel.

Se não funcionar talvez seja necessária uma analise mais detalhada do problema pelo Administrador da Rede.

Abraços

Olá Alexandre,

Pois é, me disseram que está tudo ok mesmo com MT.

- Já limpei o cache;

- Já deletei e re-criei o canal de comunicação;

- Já falei com o responsável pela segurança e a requisição para a URL do webservice está passando normal;

Continua com o mesmo erro.

Hj configurei o estado do RJ e está funcionando tudo ok, ou seja, por enquanto só MT está com problemas.

Sinceramente não sei o que pode ser...

Vc poderia me informar qual a URL do webservice de homologação está usando? (acredito ser o mesmo que o meu).

Obrigado.

Daniel

Edited by: Daniel Nahas on Jan 20, 2010 6:38 PM

Desconsiderar este post...

Usei esta mesma url que você postou aqui no fórum (https://homologacao.sefaz.mt.gov.br/nfews/NfeStatusServico) e fiz o teste de minha maquina utilizando o soapUI.

Tente acessar a url do WebService através do Internet Explorer de seu pc, utilize o mesmo certificado do PI, assim você descarta um possível problema de certificado.

Tente também criar uma HTTP Destination no Visual Administrator apontando para a url da SEFAZ, você consegue assim validar se a conexão do servidor de PI com a SEFAZ MT esta OK.

Você já tentou fazer o restart da instância?

Veja esta thread, foi de um problema que tive e algumas soluções postadas lá pode te ajudar...

Erro de IAIK eh relacionado ao certificado (seja da SEFAZ ou do seu). Tente verificar se o seu cert foi exportado de acordo com o informado aqui pelo forum (busque pelo erro "http 403" para mais informacoes) e que a cadeia do cert da SEFAZ MT esteja no seu TrustedCAs.

Uma vez teve um problema parecido com a SEFAZ-PE que outras solucoes nao tinham pois o PI faz mais validacoes do que outras solucoes (na verdade o PI faz o correto de acordo com o padrao de certificacao PKCS#12, outras solucoes que aceitavam "qq coisa").

Nao vou dizer que foi facil convence-los a trocar o certificado deles...

Abs,

Henrique.

Henrique,

Eu importei a cadeia de certificados (Autoridade Certificadora Raiz, AC Certisign G3, AC Certisign Multipla G3, ambos do "cadeado" da URL do serviço de homologação do MT) no Trusted CA do Key Storage no VA.

A exportação do nosso certificado foi feito de acordo com o manual da Certisign (Não fui eu quem fiz...). Acredito que se o problema fosse meu certificado, todos os status de serviço de todas as SEFAZ que tenho configurado, iriam dar erro, porém a SEFAZ do RJ e SP está tudo ok.

Procurei no forum mas não encontrei, a maneira de mudar o trace no J2EE para que eu possa verificar melhor qual o retorno da SEFAZ MT... Vs saberia me dizer como fazer isto?

Muito obrigado.

Daniel

Daniel,

Veja se isso te ajuda...

Abraços!

Ask a Question

Top Q&A Solution Author

User

Count