Jump to content
cjulio

Utilizar Webservices da AT

Recommended Posts

ei99045
34 minutos atrás, Smig disse:

Estou em java e pelo que percebo, isto devia resolver-se importando o certificado que enviaram no mail para a truststore do jre (jre\lib\security\cacerts) com o comando keytool, ou apontar para uma truststore específica no código (System.setProperty("javax.net.ssl.trustStore", "certPath")), mas não tive sucesso com nenhuma das duas alternativas. Recebo de volta sempre o seguinte:

Tentei usar pfx e jks, mas é igual. Verifiquei que os certificados são abertos corretamente no java com o uso de java.security.KeyStore.

Alguém em java avançou mais?

Estou com o mesmo problema. Certificados importado para cacerts e nada. SSL peer shut down incorrectly. Ligação estabelecida em TLS1.2.

Share this post


Link to post
Share on other sites
Nuno Silva

Bem, é estupido, mas aqui vai.

Solução para java, extrair em dois PEM os certificados CA enviados já por alguém aqui no forum DGITA_Issuing_CA2.pem e inserir estes certificados no pfx do cliente que é usado para se autenticar no serviço.

Usar o truststore com os novos certificados e ficou a funcionar. Override da validação só dá erro 😕 tenho de ver isto melhor, mas está a funcionar.
Boa sorte com isso.
 

  • Vote 2

Share this post


Link to post
Share on other sites
ei99045
23 minutos atrás, Nuno Silva disse:

Bem, é estupido, mas aqui vai.

Solução para java, extrair em dois PEM os certificados CA enviados já por alguém aqui no forum DGITA_Issuing_CA2.pem e inserir estes certificados no pfx do cliente que é usado para se autenticar no serviço.

Usar o truststore com os novos certificados e ficou a funcionar. Override da validação só dá erro 😕 tenho de ver isto melhor, mas está a funcionar.
Boa sorte com isso.
 

Confirmo. É estranho como tudo, mas que funciona, funciona!

Share this post


Link to post
Share on other sites
marcolopes

Ena, tantas mensagens por causa dos certificados!

Não mudou nada!... devia ser tudo "transparente"

Tenho os endpoints de TESTE a funcionar perfeitamente: https://github.com/marcolopes/dma/tree/master/org.dma.services.at/src/org/dma/services/at/test

Apenas actualizei recentemente o certificado de TESTES (no projecto)

Edited by marcolopes

The simplest explanation is usually the correct one

JAVA Utilities: https://github.com/marcolopes/dma

Share this post


Link to post
Share on other sites
JMatos
40 minutos atrás, marcolopes disse:

Ena, tantas mensagens por causa dos certificados!

Não mudou nada!... devia ser tudo "transparente"

Tenho os endpoints de TESTE a funcionar perfeitamente: https://github.com/marcolopes/dma/tree/master/org.dma.services.at/src/org/dma/services/at/test

Apenas actualizei recentemente o certificado de TESTES (no projecto)

Marco,

Utilizaste o certificado que a AT enviou esta semana?

Desde ontem ao final da tarde que não estou a conseguir comunicar em produção e também para o ambiente de testes. 

JJM

Share this post


Link to post
Share on other sites
marcolopes
38 minutes ago, JMatos said:

Marco,

Utilizaste o certificado que a AT enviou esta semana?

Desde ontem ao final da tarde que não estou a conseguir comunicar em produção e também para o ambiente de testes. 

JJM

O certificado que a AT enviou esta semana, envia todos os anos... não preciso dele para nada... nunca precisei! Presumo que não será agora que irei precisar...

Aliás, o que diz a documentação técnica sobre este certificado (estabelecimento da ligação SSL)?http://info.portaldasfinancas.gov.pt/pt/apoio_contribuinte/Documents/ComunicacaodosdadosdasfaturasaAT.pdf

Diz o seguinte:

4. Estabelecer uma ligação segura em HTTPS com o portal das finanças e utilizando o seguinte endereço de envio de dados de faturas:
https://servicos.portaldasfinancas.gov.pt:400/fews/faturas

a) Para estabelecer esta ligação é necessário utilizar o certificado SSL previamente submetido e assinado pela AT, através do processo de adesão ao envio de dados das faturas por parte dos produtores de software;

ou seja, no ambiente de testes é o certificado TesteWebServices, no ambiente de produção, é o certificado pedido pelo produtor de software através da submissão do CSR (Certificate Signing Request)

nada mais a acrescentar!

Não vou alterar qualquer código.

Edited by marcolopes
  • Vote 1

The simplest explanation is usually the correct one

JAVA Utilities: https://github.com/marcolopes/dma

Share this post


Link to post
Share on other sites
Silva Gomes
1 hora atrás, Nuno Silva disse:

Bem, é estupido, mas aqui vai.

Solução para java, extrair em dois PEM os certificados CA enviados já por alguém aqui no forum DGITA_Issuing_CA2.pem e inserir estes certificados no pfx do cliente que é usado para se autenticar no serviço.

Usar o truststore com os novos certificados e ficou a funcionar. Override da validação só dá erro 😕 tenho de ver isto melhor, mas está a funcionar.
Boa sorte com isso.
 

Olá Nuno

podes dizer como fizeste isso, por favor?

Obrigado 

Share this post


Link to post
Share on other sites
marcolopes
2 hours ago, Nuno Silva said:

Bem, é estupido, mas aqui vai.

Solução para java, extrair em dois PEM os certificados CA enviados já por alguém aqui no forum DGITA_Issuing_CA2.pem e inserir estes certificados no pfx do cliente que é usado para se autenticar no serviço.

Usar o truststore com os novos certificados e ficou a funcionar. Override da validação só dá erro 😕 tenho de ver isto melhor, mas está a funcionar.
Boa sorte com isso.
 

Mas isso está descrito em que documentação técnica de implementação?? :\\\


The simplest explanation is usually the correct one

JAVA Utilities: https://github.com/marcolopes/dma

Share this post


Link to post
Share on other sites
ei99045
6 minutos atrás, Silva Gomes disse:

Olá Nuno

podes dizer como fizeste isso, por favor?

Obrigado 

"extrair em dois PEM os certificados CA enviados já por alguém aqui no forum DGITA_Issuing_CA2.pem" -> é editar o ficheiro com um editor de texto e separar os dois blocos em dois ficheiros diferentes, por exemplo: DGITA_Issuing_CA2.pem.1 e DGITA_Issuing_CA2.pem.2.

"inserir estes certificados no pfx do cliente que é usado para se autenticar no serviço" -> é correr o comando seguinte para os dois ficheiros produzidos no passo anterior, substituindo os caminhos e password da keystore do certificado cliente.
keytool -importcert -noprompt -alias DGITA_Issuing_CA21 -file /path/to/DGITA_Issuing_CA2.pem.1 -keystore ClientCertificate-prod.p12 -storepass <password keystore>
keytool -importcert -noprompt -alias DGITA_Issuing_CA22 -file /path/to/DGITA_Issuing_CA2.pem.2 -keystore ClientCertificate-prod.p12 -storepass <password keystore>

"Usar o truststore com os novos certificados e ficou a funcionar." -> é adicionar os certificados à truststore cacerts da JVM que estiver a ser usado, por exemplo assim:

keytool -import -alias portaldasfinancas1 -keystore /path/to/jre/lib/security/cacerts -file /path/to/portaldasfinancas1.der
keytool -import -alias portaldasfinancas1 -keystore /path/to/jre/lib/security/cacerts -file /path/to/portaldasfinancas2.der
keytool -import -alias portaldasfinancas1 -keystore /path/to/jre/lib/security/cacerts -file /path/to/portaldasfinancas3.der

Os ficheiros portaldasfinancas?.pem podem ser obtidos a partir a partir de ficheiros pem com o seguinte comando:

openssl x509 -outform der -in portaldasfinancas1.pem -out portaldasfinancas1.der

E os três ficheiros podem ser obtidos a partir do PEM fornecido pela AT, mais uma vez editando com um editor de texto e separando os blocos.

  • Vote 1

Share this post


Link to post
Share on other sites
marcolopes
20 minutes ago, ei99045 said:

"extrair em dois PEM os certificados CA enviados já por alguém aqui no forum DGITA_Issuing_CA2.pem" -> é editar o ficheiro com um editor de texto e separar os dois blocos em dois ficheiros diferentes, por exemplo: DGITA_Issuing_CA2.pem.1 e DGITA_Issuing_CA2.pem.2.

"inserir estes certificados no pfx do cliente que é usado para se autenticar no serviço" -> é correr o comando seguinte para os dois ficheiros produzidos no passo anterior, substituindo os caminhos e password da keystore do certificado cliente.
keytool -importcert -noprompt -alias DGITA_Issuing_CA21 -file /path/to/DGITA_Issuing_CA2.pem.1 -keystore ClientCertificate-prod.p12 -storepass <password keystore>
keytool -importcert -noprompt -alias DGITA_Issuing_CA22 -file /path/to/DGITA_Issuing_CA2.pem.2 -keystore ClientCertificate-prod.p12 -storepass <password keystore>

"Usar o truststore com os novos certificados e ficou a funcionar." -> é adicionar os certificados à truststore cacerts da JVM que estiver a ser usado, por exemplo assim:

keytool -import -alias portaldasfinancas1 -keystore /path/to/jre/lib/security/cacerts -file /path/to/portaldasfinancas1.der
keytool -import -alias portaldasfinancas1 -keystore /path/to/jre/lib/security/cacerts -file /path/to/portaldasfinancas2.der
keytool -import -alias portaldasfinancas1 -keystore /path/to/jre/lib/security/cacerts -file /path/to/portaldasfinancas3.der

Os ficheiros portaldasfinancas?.pem podem ser obtidos a partir a partir de ficheiros pem com o seguinte comando:

openssl x509 -outform der -in portaldasfinancas1.pem -out portaldasfinancas1.der

E os três ficheiros podem ser obtidos a partir do PEM fornecido pela AT, mais uma vez editando com um editor de texto e separando os blocos.

O que eu acho que é a minha implementação está a fazer BYPASS da validação do certificado, e como tal, não estou a ser afectado: https://github.com/marcolopes/dma/blob/master/org.dma.services.at/src/org/dma/services/at/SOAPMessageHandler.java

			// Coloca o SSL socket factory no request context da ligacao a efetuar ao webservice
			KeyManagerFactory kmf = KeyManagerFactory.getInstance("SunX509");
			kmf.init(swCertificate.getKeyStore(), swCertificate.password.toCharArray());

			// adiciona um Trust Store que aceita ligacao SSL sem validar o certificado
			SSLContext sslContext = SSLContext.getInstance("TLSv1"); // JAVA8 usa TLSv2
			sslContext.init(kmf.getKeyManagers(), new TrustManager[]{new PermissiveTrustStore()}, null);

			/*
			// indica um conjunto de certificados confiaveis para estabelecer a ligacao SSL
			KeyStore ks = KeyStore.getInstance("JKS");
			ks.load(this.getClass().getClassLoader().getResourceAsStream("trustStore"), "cliente".toCharArray());
			TrustManagerFactory tmf = TrustManagerFactory.getInstance("SunX509");
			tmf.init(ks);
			SSLContext sslContext = SSLContext.getInstance("TLS");
			sslContext.init(kmf.getKeyManagers(), tmf.getTrustManagers(), null);
			*/

 


The simplest explanation is usually the correct one

JAVA Utilities: https://github.com/marcolopes/dma

Share this post


Link to post
Share on other sites
Silva Gomes
3 minutos atrás, marcolopes disse:

O que eu acho que é a minha implementação está a fazer BYPASS da validação do certificado, e como tal, não estou a ser afectado: https://github.com/marcolopes/dma/blob/master/org.dma.services.at/src/org/dma/services/at/SOAPMessageHandler.java


			// Coloca o SSL socket factory no request context da ligacao a efetuar ao webservice
			KeyManagerFactory kmf = KeyManagerFactory.getInstance("SunX509");
			kmf.init(swCertificate.getKeyStore(), swCertificate.password.toCharArray());

			// adiciona um Trust Store que aceita ligacao SSL sem validar o certificado
			SSLContext sslContext = SSLContext.getInstance("TLSv1"); // JAVA8 usa TLSv2
			sslContext.init(kmf.getKeyManagers(), new TrustManager[]{new PermissiveTrustStore()}, null);

			/*
			// indica um conjunto de certificados confiaveis para estabelecer a ligacao SSL
			KeyStore ks = KeyStore.getInstance("JKS");
			ks.load(this.getClass().getClassLoader().getResourceAsStream("trustStore"), "cliente".toCharArray());
			TrustManagerFactory tmf = TrustManagerFactory.getInstance("SunX509");
			tmf.init(ks);
			SSLContext sslContext = SSLContext.getInstance("TLS");
			sslContext.init(kmf.getKeyManagers(), tmf.getTrustManagers(), null);
			*/

 

Olá Marco,

 

eu tenho o código igual ao teu, mas mesmo assim :HTTP transport error: javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake" :(

 

Share this post


Link to post
Share on other sites
Nuno Silva
6 minutes ago, marcolopes said:

O que eu acho que é a minha implementação está a fazer BYPASS da validação do certificado, e como tal, não estou a ser afectado: https://github.com/marcolopes/dma/blob/master/org.dma.services.at/src/org/dma/services/at/SOAPMessageHandler.java


			// Coloca o SSL socket factory no request context da ligacao a efetuar ao webservice
			KeyManagerFactory kmf = KeyManagerFactory.getInstance("SunX509");
			kmf.init(swCertificate.getKeyStore(), swCertificate.password.toCharArray());

			// adiciona um Trust Store que aceita ligacao SSL sem validar o certificado
			SSLContext sslContext = SSLContext.getInstance("TLSv1"); // JAVA8 usa TLSv2
			sslContext.init(kmf.getKeyManagers(), new TrustManager[]{new PermissiveTrustStore()}, null);

			/*
			// indica um conjunto de certificados confiaveis para estabelecer a ligacao SSL
			KeyStore ks = KeyStore.getInstance("JKS");
			ks.load(this.getClass().getClassLoader().getResourceAsStream("trustStore"), "cliente".toCharArray());
			TrustManagerFactory tmf = TrustManagerFactory.getInstance("SunX509");
			tmf.init(ks);
			SSLContext sslContext = SSLContext.getInstance("TLS");
			sslContext.init(kmf.getKeyManagers(), tmf.getTrustManagers(), null);
			*/

 

Boas, 

 

Eu tb tinha o bypass e estava  a bater

new TrustManager[]{new PermissiveTrustStore()}

 

Basicamente ao adicionarmos os dois CA's ao pfx estamos a colocar lá a cadeia de certificação completa.

 

Depois de o fazer é básico :)

Qualquer coisa tb dou uma ajuda

  • Vote 1

Share this post


Link to post
Share on other sites
marcolopes
Just now, Silva Gomes said:

Olá Marco,

eu tenho o código igual ao teu, mas mesmo assim :HTTP transport error: javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake" :(

Então na segunda feira vão haver muitos clientes a berrar... E a culpa é de quem? AT? Produtor? Parece-me ser de ambos... o MANUAL TÉCNICO não informa correctamente sobre esta questão... e se até agora tudo funcionava, então a implementação do lado da AT mudou...


The simplest explanation is usually the correct one

JAVA Utilities: https://github.com/marcolopes/dma

Share this post


Link to post
Share on other sites
Silva Gomes
3 minutos atrás, Nuno Silva disse:

Boas, 

 

Eu tb tinha o bypass e estava  a bater

new TrustManager[]{new PermissiveTrustStore()}

 

Basicamente ao adicionarmos os dois CA's ao pfx estamos a colocar lá a cadeia de certificação completa.

 

Depois de o fazer é básico :)

Qualquer coisa tb dou uma ajuda

Olá, como fizeste, podes ajudar por favor?

obrigado.

Share this post


Link to post
Share on other sites
Nuno Silva
4 minutes ago, Silva Gomes said:

Olá, como fizeste, podes ajudar por favor?

obrigado.

Tens a solução em cima, mas basicamente alteras o pfx de autenticação para ter a cadeia de certificação completa e voltas a usar a truststore, o ei99045 explicou os passos todos em cima :)

Edited by Nuno Silva

Share this post


Link to post
Share on other sites
marcolopes
Just now, Nuno Silva said:

Tens a solução em cima, mas basicamente alteras o pfx de autenticação para ter a cadeia de certificação completa e voltas a usar a truststore, o Marco explicou os passos todos em cima :)

Eu não queria misturar os certificados! A implementação correcta não será implementar uma trustStore a partir do "certificado digital de SSL" enviado agora pela AT?


The simplest explanation is usually the correct one

JAVA Utilities: https://github.com/marcolopes/dma

Share this post


Link to post
Share on other sites
Nuno Silva
3 minutes ago, marcolopes said:

Eu não queria misturar os certificados! A implementação correcta não será implementar uma trustStore a partir do "certificado digital de SSL" enviado agora pela AT?

Boas,

Faz sentido, e não estás a misturar, usas na trustStore os correctos, e colocas no PFX a cadeia de certificação completa.

 

O meu stress com isto é que é a AT que cria e envia o PFX, logo teremos de o manipular sempre depois de recebido, mas além disto n há nada de novo, estão sempre a fazer ...

Mas se tens dúvidas podes fazer os testes que eu fiz com o openssl -debug e -status, e percebes que o problema está logo no CA.

Edited by Nuno Silva
language

Share this post


Link to post
Share on other sites
Nuno Silva
51 minutes ago, marcolopes said:

Mas isso está descrito em que documentação técnica de implementação?? :\\\

Infelizmente tive de  perder muito tempo que não tinha para resolver isto, deveria estar, sem dúvida que sim, eu teria ficado agradecido :/

Share this post


Link to post
Share on other sites
Silva Gomes
33 minutos atrás, Nuno Silva disse:

Tens a solução em cima, mas basicamente alteras o pfx de autenticação para ter a cadeia de certificação completa e voltas a usar a truststore, o ei99045 explicou os passos todos em cima :)

Olá, 
não estou mesmo a conseguir... :(

Podes ajudar Nuno, por favor?

Share this post


Link to post
Share on other sites
pmmachado
1 hora atrás, ei99045 disse:

"extrair em dois PEM os certificados CA enviados já por alguém aqui no forum DGITA_Issuing_CA2.pem" -> é editar o ficheiro com um editor de texto e separar os dois blocos em dois ficheiros diferentes, por exemplo: DGITA_Issuing_CA2.pem.1 e DGITA_Issuing_CA2.pem.2.

"inserir estes certificados no pfx do cliente que é usado para se autenticar no serviço" -> é correr o comando seguinte para os dois ficheiros produzidos no passo anterior, substituindo os caminhos e password da keystore do certificado cliente.
keytool -importcert -noprompt -alias DGITA_Issuing_CA21 -file /path/to/DGITA_Issuing_CA2.pem.1 -keystore ClientCertificate-prod.p12 -storepass <password keystore>
keytool -importcert -noprompt -alias DGITA_Issuing_CA22 -file /path/to/DGITA_Issuing_CA2.pem.2 -keystore ClientCertificate-prod.p12 -storepass <password keystore>

"Usar o truststore com os novos certificados e ficou a funcionar." -> é adicionar os certificados à truststore cacerts da JVM que estiver a ser usado, por exemplo assim:

keytool -import -alias portaldasfinancas1 -keystore /path/to/jre/lib/security/cacerts -file /path/to/portaldasfinancas1.der
keytool -import -alias portaldasfinancas1 -keystore /path/to/jre/lib/security/cacerts -file /path/to/portaldasfinancas2.der
keytool -import -alias portaldasfinancas1 -keystore /path/to/jre/lib/security/cacerts -file /path/to/portaldasfinancas3.der

Os ficheiros portaldasfinancas?.pem podem ser obtidos a partir a partir de ficheiros pem com o seguinte comando:

openssl x509 -outform der -in portaldasfinancas1.pem -out portaldasfinancas1.der

E os três ficheiros podem ser obtidos a partir do PEM fornecido pela AT, mais uma vez editando com um editor de texto e separando os blocos.

Uma questão:

Para gerar "nosso" certificado utilizamos o comando

openssl pkcs12 -export -in 500999999.cer -inkey 500999999.key -out 500999999.pfx

para criar o .pfx que vamos utilizar na autenticação. Julgo que esse certificado não tem a cadeia completa no certificado.

O que estás a dizer  é inserir os certificados da cadeia completa no "nosso" certificado e depois utilizar esse para autenticação?

Tenho uma solução desenvolvida em .net desde 2013 que até sexta sempre funcionou, mesmo nos outros anos em que a AT alterou o certificado ... e neste momento nada comunica.

Abc

Share this post


Link to post
Share on other sites
Nuno Silva
21 minutes ago, Silva Gomes said:

Olá, 
não estou mesmo a conseguir... :(

Podes ajudar Nuno, por favor?

Boas, o que n consegues fazer?

 

Share this post


Link to post
Share on other sites
Nuno Silva
2 minutes ago, pmmachado said:

Uma questão:

Para gerar "nosso" certificado utilizamos o comando

openssl pkcs12 -export -in 500999999.cer -inkey 500999999.key -out 500999999.pfx

para criar o .pfx que vamos utilizar na autenticação. Julgo que esse certificado não tem a cadeia completa no certificado.

O que estás a dizer  é inserir os certificados da cadeia completa no "nosso" certificado e depois utilizar esse para autenticação?

Tenho uma solução desenvolvida em .net desde 2013 que até sexta sempre funcionou, mesmo nos outros anos em que a AT alterou o certificado ... e neste momento nada comunica.

Abc

Boas,

 

Sim, adicionar a cadeia completa no pfx, podes usar o openssl ou fazer as cenas mais assistidas com o keystore explorer.

 

Share this post


Link to post
Share on other sites
Silva Gomes
1 minuto atrás, Nuno Silva disse:

Boas, o que n consegues fazer?

 

Boas, 
queria gerir isto a baixo, mas dentro do java... podes ajudar?



 

"inserir estes certificados no pfx do cliente que é usado para se autenticar no serviço" -> é correr o comando seguinte para os dois ficheiros produzidos no passo anterior, substituindo os caminhos e password da keystore do certificado cliente.
keytool -importcert -noprompt -alias DGITA_Issuing_CA21 -file /path/to/DGITA_Issuing_CA2.pem.1 -keystore ClientCertificate-prod.p12 -storepass <password keystore>
keytool -importcert -noprompt -alias DGITA_Issuing_CA22 -file /path/to/DGITA_Issuing_CA2.pem.2 -keystore ClientCertificate-prod.p12 -storepass <password keystore>

"Usar o truststore com os novos certificados e ficou a funcionar." -> é adicionar os certificados à truststore cacerts da JVM que estiver a ser usado, por exemplo assim:

keytool -import -alias portaldasfinancas1 -keystore /path/to/jre/lib/security/cacerts -file /path/to/portaldasfinancas1.der
keytool -import -alias portaldasfinancas1 -keystore /path/to/jre/lib/security/cacerts -file /path/to/portaldasfinancas2.der
keytool -import -alias portaldasfinancas1 -keystore /path/to/jre/lib/security/cacerts -file /path/to/portaldasfinancas3.der

 

 

Share this post


Link to post
Share on other sites
marcolopes
2 minutes ago, Nuno Silva said:

Boas,

Sim, adicionar a cadeia completa no pfx, podes usar o openssl ou fazer as cenas mais assistidas com o keystore explorer.

Eu acho que não deviamos misturar alhos com bugalhos...

Exportei o CER para uma KEYSTORE e adicionei-a a uma TRUST STORE de validação no código...  Não mexi no certificado do produtor (PFX)

para já passa em testes...

Edited by marcolopes

The simplest explanation is usually the correct one

JAVA Utilities: https://github.com/marcolopes/dma

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...

Important Information

By using this site you accept our Terms of Use and Privacy Policy. We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.