Utilizar Webservices da AT

[furiousangelpt]

Uma pergunta estupida, podemos utilizar o nosso PFX no servidor de testes? 
 

funciona tudo bem com o PFX de Test e foi so mesmo adicionar a tal linha para utilizar o Tls v1.2, só fico com a questão de se é possível utilizar o nosso, pq com esse não consigo fazer o handshake inicial. Já pedi um novo pro caso se for. tirando isso boa sorte amanha.  

[marcolopes]

On 1/5/2025 at 3:22 PM, trs80 said:

Boas,

No inicio da comunicação de DTs eu usei a applet da AT como base.

Nunca consegui por a funcionar em Java8 com TLS1.2 por isso mantive java7 com TLS.

Aparentemente agora vai deixar de funcionar (com o ultimo Testewebservices.pfx) tenho  o erro "DER input not an octet string"

Isto acontece tanto com TLS, TLSV1.2, java 7 ou java 8

Alguem tem conhecimento de alguma versao actualizada da Applet ?

Obrigado

Java é "comigo" 😄

Então vamos por partes

1) Testewebservices.pfx deixou de ser compatível, e se reparares umas boas páginas atrás, já aqui foi discutido, e com espírito de entreajuda, chegamos à conclusão que uma "bela" conversão do PFX em modo de compatibilidade resolve o problema. Aqui ficam os comandos (OpenSSL 3.x) para a referida conversão

echo CONVERTE O CERTIFICADO DE TESTES (compatibilidade com JAVA 7)
del %OUTPUT_FOLDER%\TesteWebservices.pfx
openssl pkcs12 -nodes -in TesteWebservices.pfx -out %OUTPUT_FOLDER%\TesteWebservices.pem -nodes -passin pass:TESTEwebservice
openssl pkcs12 -legacy -keypbe PBE-SHA1-3DES -certpbe PBE-SHA1-3DES -export -in %OUTPUT_FOLDER%\TesteWebservices.pem -out %OUTPUT_FOLDER%\TesteWebservices.pfx -passout pass:TESTEwebservice

Isto resolve a questão do "DER input not an octet string" ao ler o certificado com JAVA NATIVO

NOTA: Utilizo sempre um OUTPUT FOLDER distinto para a colocação dos certificados "finais" mantendo SEMPRE os originais

2) O problema do HANDSHAKE em JAVA 7 está relacionado com o que se tem vindo a discutir "agora", ou seja, as CIFRAS que estão disponíveis para executar a ligação SEGURA TLS 1.x, Pelo menos UMA cifra aceite pela AT deve ser suportada pelo CLIENT (o que não acontece nos ENDPOINTS de TESTES - não confirmei nos endpoints de produção, o que para mim é irrelevante, pois parto do princípio que o que funciona em TESTES funciona em PRODUÇÃO - e que parece não ser a realidade, pois nem todas as cifras suportadas nos ENDPOINTS de TESTES são suportadas nos ENDPOINTS de PRODUÇÃO! mais uma salgalhada da AT...)

Para resolver este problema, ou usas JAVA 8 nos teus ambientes de TESTE e PRODUÇÃO, ou então fazes como eu, e consideras a opção de utilizar uma LIB que não dependa do JAVA para implementar o PROVIDER de SEGURANÇA (TLS). No meu caso, estou a optar pelas LIBS já minhas conhecidas da Bouncy Castle (já discutido páginas atrás)
 

[marcolopes]

On 1/5/2025 at 4:32 PM, furiousangelpt said:

o utilizador de testes esta a funcionar? 

User = "599999993/0037"
Pass = "TESTE"

<faultcode>33</faultcode>
<faultstring>Ocorreu um erro na autenticacao dos contribuintes.</faultstring>
<faultactor/>

O UTILIZADOR de TESTE é "599999993/0037" com a password "testes1234"

Estava a tentar encontrar a razão da password ser "testes1234" mas não encontro qualquer informação na documentação técnica...

Onde é que a AT informa / informou claramente qual é o utilizador de TESTES e respectiva password?

Edited January 5, 2025 at 08:15 PM by marcolopes

[trs80]

Em 05/01/2025 às 19:22, marcolopes disse:

Java é "comigo" 😄

Então vamos por partes

1) Testewebservices.pfx deixou de ser compatível, e se reparares umas boas páginas atrás, já aqui foi discutido, e com espírito de entreajuda, chegamos à conclusão que uma "bela" conversão do PFX em modo de compatibilidade resolve o problema. Aqui ficam os comandos (OpenSSL 3.x) para a referida conversão

echo CONVERTE O CERTIFICADO DE TESTES (compatibilidade com JAVA 7)
del %OUTPUT_FOLDER%\TesteWebservices.pfx
openssl pkcs12 -nodes -in TesteWebservices.pfx -out %OUTPUT_FOLDER%\TesteWebservices.pem -nodes -passin pass:TESTEwebservice
openssl pkcs12 -legacy -keypbe PBE-SHA1-3DES -certpbe PBE-SHA1-3DES -export -in %OUTPUT_FOLDER%\TesteWebservices.pem -out %OUTPUT_FOLDER%\TesteWebservices.pfx -passout pass:TESTEwebservice

Isto resolve a questão do "DER input not an octet string" ao ler o certificado com JAVA NATIVO

NOTA: Utilizo sempre um OUTPUT FOLDER distinto para a colocação dos certificados "finais" mantendo SEMPRE os originais

2) O problema do HANDSHAKE em JAVA 7 está relacionado com o que se tem vindo a discutir "agora", ou seja, as CIFRAS que estão disponíveis para executar a ligação SEGURA TLS 1.x, Pelo menos UMA cifra aceite pela AT deve ser suportada pelo CLIENT (o que não acontece nos ENDPOINTS de TESTES - não confirmei nos endpoints de produção, o que para mim é irrelevante, pois parto do princípio que o que funciona em TESTES funciona em PRODUÇÃO - e que parece não ser a realidade, pois nem todas as cifras suportadas nos ENDPOINTS de TESTES são suportadas nos ENDPOINTS de PRODUÇÃO! mais uma salgalhada da AT...)

Para resolver este problema, ou usas JAVA 8 nos teus ambientes de TESTE e PRODUÇÃO, ou então fazes como eu, e consideras a opção de utilizar uma LIB que não dependa do JAVA para implementar o PROVIDER de SEGURANÇA (TLS). No meu caso, estou a optar pelas LIBS já minhas conhecidas da Bouncy Castle (já discutido páginas atrás)
 

Muito obrigado pela resposta.

Entretanto eu resolvi o problema recriando o pfx de forma semelhante

Mudei para java8 e indico TLSv1.2 e no IDE - netbeans 8.2 - (dont ask) funciona comunica, recebo o codigo e um aviso do ATCUD e da serie, mas funciona.

Fazendo build e correndo o JAR (quer com JRE 8 ou JDK 8), tenho handshake failure - estou a arrancar os cabelos que nao tenho...

Vou ver o BouncyCastle que imagino funcione em Java7

Obrigado mais uma vez

E se tiveres alguma ideia quanto ao meu problema - inedito (suspeito ter a ver com libs da SUN)

[marcolopes]

On 1/5/2025 at 8:34 PM, trs80 said:

Muito obrigado pela resposta.

Entretanto eu resolvi o problema recriando o pfx de forma semelhante

Mudei para java8 e indico TLSv1.2 e no IDE - netbeans 8.2 - (dont ask) funciona comunica, recebo o codigo e um aviso do ATCUD e da serie, mas funciona.

Fazendo build e correndo o JAR (quer com JRE 8 ou JDK 8), tenho handshake failure - estou a arrancar os cabelos que nao tenho...

Vou ver o BouncyCastle que imagino funcione em Java7

Obrigado mais uma vez

E se tiveres alguma ideia quanto ao meu problema - inedito (suspeito ter a ver com libs da SUN)

NÃO podes ter problemas no handshake com JAVA 8 usando as classes NATIVAS do JAVA. Eu não tenho.

Tenho problemas no JAVA 7.

E como preciso de JAVA 7 para o ambiente de TESTES, tive de encontrar solução... e depois de DEZENAS de voltas, a única solução que encontrei foi criar um novo projecto Bouncy Castle (a versão para Java 7) e incorporar o mesmo no projecto de Webservices da AT. Neste caso, a inicialização do SSL CONTEXT é feita da seguinte forma:

SSLContext sslContext = SSLContext.getInstance("TLSv1.2", new BouncyCastleJsseProvider());

NOTA: Este new BouncyCastleJsseProvider() está definido em ENUMerador de PROVIDERS de forma "estática" por forma a evitar uma instanciação sistemática a cada comunicação...

Como estás a usar JAVA 8 ou superior, até mesmo no ambiente de TESTES, tudo deve correr sem problemas utilizando apenas as classes JAVA nativas...

Edited January 5, 2025 at 08:46 PM by marcolopes

[marcolopes]

On 1/5/2025 at 8:34 PM, trs80 said:

Muito obrigado pela resposta.

Entretanto eu resolvi o problema recriando o pfx de forma semelhante

Mudei para java8 e indico TLSv1.2 e no IDE - netbeans 8.2 - (dont ask) funciona comunica, recebo o codigo e um aviso do ATCUD e da serie, mas funciona.

Fazendo build e correndo o JAR (quer com JRE 8 ou JDK 8), tenho handshake failure - estou a arrancar os cabelos que nao tenho...

Uma NOTA para dizer que por vezes (muito raras!) também tenho problemas ao correr a versão EXPORTADA!! Por vezes também me apetece arrancar os cabelos 😄

Portanto, sim, entendo o teu pesadelo! Existem situações específicas que dependem muito do próprio IDE e das configurações são muito sensíveis, até mesmo em relação a prioridades de PACKAGES que podem estar "duplicadas" porque são usadas por outras LIBS, por exemplo...

Há sempre que testar a versão EXPORTADA para verificar a possibilidade de problemas.

[trs80]

@marcolopes mais uma vez obrigado.

Algo muda entre a execucao no netbeans e a execucao "stand alone",

Não consigo perceber o quê, ja tentei com duas versoes de java 8 (oracle e zulu)

Mesmo na Zulu tenho o mesmo comportamento, no IDE funciona, Jar => erro

Vou tentar o Bouncy Castle

Obrigado

[marcolopes]

Em 05/01/2025 às 22:19, trs80 disse:

@marcolopes mais uma vez obrigado.

Algo muda entre a execucao no netbeans e a execucao "stand alone",

Não consigo perceber o quê, ja tentei com duas versoes de java 8 (oracle e zulu)

Mesmo na Zulu tenho o mesmo comportamento, no IDE funciona, Jar => erro

Vou tentar o Bouncy Castle

Obrigado

Neste momento não consigo comunicar no ambiente de TESTES com JAVA 8! (seja com Bouncy Castel ou JAVA nativo)

"Erro de Autenticação/Autorização - Pedido do Cliente" (que geralmente é um problema da HORA - mas não pode ser neste caso)

Isto está cada vez melhor...

[joamag]

Em 05/01/2025 às 22:28, marcolopes disse:

Neste momento não consigo comunicar no ambiente de TESTES com JAVA 8! (seja com Bouncy Castel ou JAVA nativo)

"Erro de Autenticação/Autorização - Pedido do Cliente" (que geralmente é um problema da HORA - mas não pode ser neste caso)

Isto está cada vez melhor...

Penso que o erro (Erro de Autenticação/Autorização - Pedido do Cliente) já desapareceu.

Tenho obtido esse erro de forma errática (no endpoint de testes) nos últimos dias.

[marcolopes]

On 1/5/2025 at 10:37 PM, joamag said:

Penso que o erro (Erro de Autenticação/Autorização - Pedido do Cliente) já desapareceu.

Tenho obtido esse erro de forma errática (no endpoint de testes) nos últimos dias.

Realmente!! Já estava a dar em doido... fiz um teste da versão EXPORTADA e tudo OK em JAVA 7 ou 8...

Agora dentro do IDE já funciona também...

Azar dos azares, era do lado da AT...

[trs80]

@marcolopes Quanto ao BC, colocar o provider à malandro não deve ser suficiente.

Eu acho que o problema está em estar a usar baseado na aplet antiga da AT. (usa o JAXWS)

Se me permites a pergunta, no teu caso estás a usar a aplet, conseguiste apenas colocando o provider ou tiveste de refazer tudo ?

Obrigado mais uma vez.

Amanha continua-se

[marcolopes]

On 1/5/2025 at 10:48 PM, trs80 said:

@marcolopes Quanto ao BC, colocar o provider à malandro não deve ser suficiente.

Eu acho que o problema está em estar a usar baseado na aplet antiga da AT. (usa o JAXWS)

Se me permites a pergunta, no teu caso estás a usar a aplet, conseguiste apenas colocando o provider ou tiveste de refazer tudo ?

Obrigado mais uma vez.

Amanha continua-se

Vou responder em privado porque já começamos a entrar em situações demasiado específicas relativas a JAVA

[RPA]

On 1/5/2025 at 5:50 PM, furiousangelpt said:

Uma pergunta estupida, podemos utilizar o nosso PFX no servidor de testes? 
 

funciona tudo bem com o PFX de Test e foi so mesmo adicionar a tal linha para utilizar o Tls v1.2, só fico com a questão de se é possível utilizar o nosso, pq com esse não consigo fazer o handshake inicial. Já pedi um novo pro caso se for. tirando isso boa sorte amanha.  

Olá,

Só quero dar uma dica, que comigo ajudou e bastante: submeter a questão ao chatGPT, fornecendo o texto da mensagem de email e o tipo de sistema em uso (Java, Linux ou Widows, etc). Não foi à primeira mas ao longo do processo, erro para lá erro para cá, obtive respostas bastante úteis. 

Atualmente tenho tudo pronto para entrar em produção mas o servidor da AT ainda está a responder ao certificado antigo... Espero que ajude

[furiousangelpt]

Já alteraram as limitações de Produção?  

[Sergio.]

Bom dia,
A alteração foi feita pela AT.
 

Version: 2.1.5 Windows 64-bit (Mingw)
OpenSSL 3.0.14 4 Jun 2024

Connected to 62.28.254.207

Testing SSL server servicos.portaldasfinancas.gov.pt on port 401 using SNI name servicos.portaldasfinancas.gov.pt

  SSL/TLS Protocols:
SSLv2     disabled
SSLv3     disabled
TLSv1.0   disabled
TLSv1.1   disabled
TLSv1.2   enabled
TLSv1.3   enabled

  TLS Fallback SCSV:
Server supports TLS Fallback SCSV

  TLS renegotiation:
Session renegotiation not supported

  TLS Compression:
Compression disabled

  Heartbleed:
TLSv1.3 not vulnerable to heartbleed
TLSv1.2 not vulnerable to heartbleed

  Supported Server Cipher(s):
Preferred TLSv1.3  128 bits  TLS_AES_128_GCM_SHA256        Curve 25519 DHE 253
Accepted  TLSv1.3  256 bits  TLS_AES_256_GCM_SHA384        Curve 25519 DHE 253
Accepted  TLSv1.3  256 bits  TLS_CHACHA20_POLY1305_SHA256  Curve 25519 DHE 253
Preferred TLSv1.2  128 bits  ECDHE-RSA-AES128-GCM-SHA256   Curve P-256 DHE 256
Accepted  TLSv1.2  256 bits  ECDHE-RSA-AES256-GCM-SHA384   Curve P-256 DHE 256
Accepted  TLSv1.2  256 bits  ECDHE-RSA-CHACHA20-POLY1305   Curve P-256 DHE 256

  Server Key Exchange Group(s):
TLSv1.3  128 bits  secp256r1 (NIST P-256)
TLSv1.3  192 bits  secp384r1 (NIST P-384)
TLSv1.3  128 bits  x25519
TLSv1.3  112 bits  ffdhe2048
TLSv1.3  128 bits  ffdhe3072
TLSv1.3  150 bits  ffdhe4096
TLSv1.2  128 bits  secp256r1 (NIST P-256)
TLSv1.2  192 bits  secp384r1 (NIST P-384)
TLSv1.2  128 bits  x25519

  SSL Certificate:
Signature Algorithm: sha256WithRSAEncryption
RSA Key Strength:    2048

Subject:  *.portaldasfinancas.gov.pt
Altnames: DNS:*.portaldasfinancas.gov.pt, DNS:portaldasfinancas.gov.pt
Issuer:   Sectigo RSA Organization Validation Secure Server CA

Not valid before: Oct 16 00:00:00 2024 GMT
Not valid after:  Nov 15 23:59:59 2025 GMT

[Tiago Martins]

Bom dia! Alguém com problemas em comunicar guias à AT ?

[trs80]

On 1/6/2025 at 10:56 AM, furiousangelpt said:

Já alteraram as limitações de Produção?  

Aparentemente sim, já surgem erros no meu programa.

 

[karlynhuz]

On 1/6/2025 at 11:21 AM, Tiago Martins said:

Bom dia! Alguém com problemas em comunicar guias à AT ?

Bom dia. Parece que sim. Acabei de receber uma chamada de um cliente que também não consegue comunicar documentos de transporte. 

[trs80]

Update:
O problema que tive de comunicar em IDE e não comunicar em execução normal (JAR) só acontece na minha máquina,

Para quem usa o antigo codigo da AT as alterações que fiz foram minimas:

1 - SSLContext sslContext = SSLContext.getInstance("TLSv1.2");

2 - SOAPClientMessageHeaderHandler:

                SOAPHeader sh = envelope.getHeader(); // java 8 - the header is already defined
                if (sh == null) {
                    sh = envelope.addHeader(); // java 7

               }

No java8 o header já está definido e o addHeader falha

Foi as únicas alteracoes necessarias alem de correr com o Java8

[marcolopes]

On 1/6/2025 at 11:39 AM, trs80 said:

Update:
O problema que tive de comunicar em IDE e não comunicar em execução normal (JAR) só acontece na minha máquina,

Para quem usa o antigo codigo da AT as alterações que fiz foram minimas:

1 - SSLContext sslContext = SSLContext.getInstance("TLSv1.2");

2 - SOAPClientMessageHeaderHandler:

                SOAPHeader sh = envelope.getHeader(); // java 8 - the header is already defined
                if (sh == null) {
                    sh = envelope.addHeader(); // java 7

               }

No java8 o header já está definido e o addHeader falha

Foi as únicas alteracoes necessarias alem de correr com o Java8

ahhhhhhhhh! Também esbarrei nesse problema!!! (mas esse não é de agora...)

Consulta o meu código em: https://github.com/marcolopes/dma/blob/master/org.dma.services.at/src/org/dma/services/at/SOAPMessageHandler.java

Quote

            // Create SOAP Header for SOAP envelope
            SOAPEnvelope envelope = smc.getMessage().getSOAPPart().getEnvelope();
            if (envelope.getHeader()==null) envelope.addHeader(); // JAVA 8
            envelope.getHeader().addChildElement(securityHeader);

 

Edited January 6, 2025 at 12:03 PM by marcolopes