Ir para o conteúdo
cjulio

Utilizar Webservices da AT

Mensagens Recomendadas

antistes

O problema está no certificado da AT. Após testar verifiquei que a solução do jvarandas  funciona porque porque passou o CURL_SSLVERSION_SSLv3 como uma string e não como uma constante ignorando o método de autenticação.

No .NET se comentarem a linha que indica o protocolo ( SecurityProtocol = SecurityProtocolType.Ssl3 ) já funciona.

De qualquer modo penso que esta será uma solução temporária.

  • Voto 1

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
brsqueiros

Bom dia,

Já alguém conseguiu comunicar com o Webservice Aduaneiro, mais especificamente o SISTEMA SICEU, cujo endereço de testes é https://servicos.portaldasfinancas.gov.pt:802/jsp/externalWebservice.jsp?external=siceuqualidadews

Tentei replicar o mesmo principio do webservice das comunicações de transporte, mas obtenho sempre o erro faultcode 33, Falha comunicacao com Servidor de Autenticacao (500). Para me certificar que o WS está a funcionar corretamente configurei no SOAPUi e funciona bem.

Saudações

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
Jonh
36 minutos atrás, brsqueiros disse:

Bom dia,

Já alguém conseguiu comunicar com o Webservice Aduaneiro, mais especificamente o SISTEMA SICEU, cujo endereço de testes é https://servicos.portaldasfinancas.gov.pt:802/jsp/externalWebservice.jsp?external=siceuqualidadews

Tentei replicar o mesmo principio do webservice das comunicações de transporte, mas obtenho sempre o erro faultcode 33, Falha comunicacao com Servidor de Autenticacao (500). Para me certificar que o WS está a funcionar corretamente configurei no SOAPUi e funciona bem.

Saudações

Deve ser o mesmo problema de ligação dos anteriores, não estás a validar / confiar na nova cadeia de certificação do novo certificado de SSL  e como usas java a truststore não tem a cadeia a nova cadeia de certificação.

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
brsqueiros
43 minutos atrás, Jonh disse:

Deve ser o mesmo problema de ligação dos anteriores, não estás a validar / confiar na nova cadeia de certificação do novo certificado de SSL  e como usas java a truststore não tem a cadeia a nova cadeia de certificação.

O programa está todo desenvolvido em .net e ainda só estou a utilizar os certificados disponibilizados pela AT para testes.

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
PMoura

Bom dia.

Entrei há pouco em contacto com a AT que me indicou que procederam ontem a uma alteração dos certificados SSL.

Indicaram também que informaram os produtores de software desta alteração (há cerca de um mês).

Algum de vocês recebeu esta informação?

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
hobbit
42 minutos atrás, PMoura disse:

Bom dia.

Entrei há pouco em contacto com a AT que me indicou que procederam ontem a uma alteração dos certificados SSL.

Indicaram também que informaram os produtores de software desta alteração (há cerca de um mês).

Algum de vocês recebeu esta informação?

Do meu lado nada..também nos disseram isso mas não temos registo desse email

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
hobbit
3 horas atrás, antistes disse:

O problema está no certificado da AT. Após testar verifiquei que a solução do jvarandas  funciona porque porque passou o CURL_SSLVERSION_SSLv3 como uma string e não como uma constante ignorando o método de autenticação.

No .NET se comentarem a linha que indica o protocolo ( SecurityProtocol = SecurityProtocolType.Ssl3 ) já funciona.

De qualquer modo penso que esta será uma solução temporária.

Obrigado, pegando na sugestão data aplicamos no código o sugerido e adicionalmente o seguinte:

.ServiceCertificate.Authentication.CertificateValidationMode = X509CertificateValidationMode.None;

ServiceCertificate.Authentication.RevocationMode = X509RevocationMode.NoCheck;

E ficou a funcionar.

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
RikFonseca
53 minutos atrás, hobbit disse:

Obrigado, pegando na sugestão data aplicamos no código o sugerido e adicionalmente o seguinte:

.ServiceCertificate.Authentication.CertificateValidationMode = X509CertificateValidationMode.None;

ServiceCertificate.Authentication.RevocationMode = X509RevocationMode.NoCheck;

E ficou a funcionar.

Boas,

Será que podias indicar o que preciso de importar para utilizar o ServiceCertificate ?

Obrigado

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
PMoura
1 hora atrás, hobbit disse:

Do meu lado nada..também nos disseram isso mas não temos registo desse email

Mas que certificados é que mudaram? Só estou a ver que possa ser o certificado SSL do webserver?
E se sim, algum de vocês já conseguiu obter esse novo certificado?

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
hobbit
36 minutos atrás, RikFonseca disse:

Boas,

Será que podias indicar o que preciso de importar para utilizar o ServiceCertificate ?

Obrigado

Boa Tarde:

Provavelmente faz mais sentido assim: ClientCredentials.ServiceCertificate.Authentication.CertificateValidationMode assim como o outro.

Este objeto deverá fazer parte do contrato que permite falar com a AT.

 

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
hobbit
17 minutos atrás, PMoura disse:

Mas que certificados é que mudaram? Só estou a ver que possa ser o certificado SSL do webserver?
E se sim, algum de vocês já conseguiu obter esse novo certificado?

Boa Tarde:

Supostamente mudaram o certificado que a AT usa quando faz a negociação SSL com o cliente. Esse nunca é disponibilizado. A questão deverá ser que o novo Certificado que é usado na negociação deverá estar a ser certificado por outros certificados que não temos na nossa maquina e como tal isso irá falhar pois não é Trusted. Isto não é o certificado da invocação WebServices que usamos para assinar/cifrar o pedido, será se bem entendo o ligado ao canal SSL.

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
Jonh
3 horas atrás, hobbit disse:

Boa Tarde:

Supostamente mudaram o certificado que a AT usa quando faz a negociação SSL com o cliente. Esse nunca é disponibilizado. A questão deverá ser que o novo Certificado que é usado na negociação deverá estar a ser certificado por outros certificados que não temos na nossa maquina e como tal isso irá falhar pois não é Trusted. Isto não é o certificado da invocação WebServices que usamos para assinar/cifrar o pedido, será se bem entendo o ligado ao canal SSL.

Como já tinha referido do certificado digital de SSL foi mudado. O certificado atual é assinado pela COMODO, e alguns sistemas ainda não têm essa entidade certificadora, pode ser obtido quando se acede a um sitio da AT que esteja em https e fazer ver certificado e depois exportar, se se ligar para o Portal Questões Técnicas eles esclarecem.

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
antseq
18 horas atrás, Jonh disse:

Como já tinha referido do certificado digital de SSL foi mudado. O certificado atual é assinado pela COMODO, e alguns sistemas ainda não têm essa entidade certificadora, pode ser obtido quando se acede a um sitio da AT que esteja em https e fazer ver certificado e depois exportar, se se ligar para o Portal Questões Técnicas eles esclarecem.

Boa tarde,

Tenho acesso limitado a internet e duas questões, agradeço desde já quem puder ajudar:

1) liguei agora para a AT, 217206707, teclas 1/5/3 e disseram me que nada mudou do lado deles, nem o certificado!? Para que número é que ligaram para obter informações + técnicas?

2) na minha aplicação .net, já tinha aquela linha ...ssl3 comentada há muito muito tempo e mesmo assim a aplicação não comunica guias. Há algo mais a fazer?

Desde já obrigado.

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
Portelinha
21 minutos atrás, antseq disse:

Boa tarde,

Tenho acesso limitado a internet e duas questões, agradeço desde já quem puder ajudar:

1) liguei agora para a AT, 217206707, teclas 1/5/3 e disseram me que nada mudou do lado deles, nem o certificado!? Para que número é que ligaram para obter informações + técnicas?

2) na minha aplicação .net, já tinha aquela linha ...ssl3 comentada há muito muito tempo e mesmo assim a aplicação não comunica guias. Há algo mais a fazer?

Desde já obrigado.

Boa tarde,

a minha aplicação também foi desenvolvida em .net e estou a comunicar sem problemas.

Verifica as data dos certificados tanto do cer (ChaveCifraPublicaAT2020.cer) como o pfx (chave privada)

não sei no momento de comunicares importar os dados dos certificados ou instalas no pc, se for a última valida no gestor de certificados tanto do utilizador como do pc a data dos mesmos, mas valida caso tb comunicas sem instalar pois por algum motivo podes ter certificados instalados e são subpostos. 

Certificados pc: certlm.msc

Certificados utilizador: certmgr.msc

Abraço

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
brsqueiros

B

37 minutos atrás, Portelinha disse:

Boa tarde,

a minha aplicação também foi desenvolvida em .net e estou a comunicar sem problemas.

Verifica as data dos certificados tanto do cer (ChaveCifraPublicaAT2020.cer) como o pfx (chave privada)

não sei no momento de comunicares importar os dados dos certificados ou instalas no pc, se for a última valida no gestor de certificados tanto do utilizador como do pc a data dos mesmos, mas valida caso tb comunicas sem instalar pois por algum motivo podes ter certificados instalados e são subpostos. 

Certificados pc: certlm.msc

Certificados utilizador: certmgr.msc

Abraço

Boa tarde,

Eles alteraram o certificado, pois o emissor agora é COMODO, o ideal será realizar download deste do portal da AT, instalar e exportar como .cer.

De seguida altera a aplicação e chame esse novo .cer tudo o resto mantenha igual pois a única alteração foi essa. Este foi o procedimento que efetuei na minha aplicação .NET e está a funcionar sem qualquer problema.

Abc

 

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
RikFonseca
2 horas atrás, antseq disse:

Boa tarde,

Tenho acesso limitado a internet e duas questões, agradeço desde já quem puder ajudar:

1) liguei agora para a AT, 217206707, teclas 1/5/3 e disseram me que nada mudou do lado deles, nem o certificado!? Para que número é que ligaram para obter informações + técnicas?

2) na minha aplicação .net, já tinha aquela linha ...ssl3 comentada há muito muito tempo e mesmo assim a aplicação não comunica guias. Há algo mais a fazer?

Desde já obrigado.

Boa tarde,

Como já foi referido acima, a AT alterou o certificado do lado do servidor, que foi emitido pela COMODO. O certificado raiz da Comodo  não está instalado por defeito nos PCs, mas pode ser instalado manualmente (mas obrigaria a instalar em todos os postos onde tenhas a aplicação instalada...).

Há outra hipótese, sugerida acima pelo hobbit, que é a de  ignorar a validação do certificado remoto ao abrir a ligação ao servidor da AT.

Não consegui implementar daquela forma, mas encontrei na net outro método, que consiste em utilizar o TLS12 e implementar um callback para validar o certificado. Como me encontro de férias, a rotina de validação passou a retornar sempre True... Quando retornar, implemento validação pelo certificado raiz para não deixar isto tão vulnerável...

 

O que alterei foi (VB.net):

'------ Na rotina de comunicação:
ServicePointManager.SecurityProtocol = SecurityProtocolType.TLS12 'A constante só existe na framework 4.5, mas o valor = 3072
ServicePointManager.ServerCertificateValidationCallback = New RemoteCertificateValidationCallback(AddressOf ValidateCertificate)
'--------------------------------

'Callback de validação (para já aceita tudo, mais tarde implemento a validação):
Private Shared Function ValidateCertificate(ByVal sender As Object, ByVal certificate As X509Certificate, ByVal chain As X509Chain, ByVal sslPolicyErrors As SslPolicyErrors) As Boolean
  Dim validationResult As Boolean
  validationResult = True
  '
  ' policy code here ...
  '
  Return validationResult
End Function


Entretanto, hoje já responderam do suporte, onde enviaram o certificado, sem responder às restantes questões, nomeadamente a comprovativo de comunicação destas alterações, do facto de estarem a fazer isto num mês tradicionalmente de férias, da falta de apoio/conhecimentos da parte das linhas de apoio, etc...

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
antseq
23 horas atrás, antseq disse:

Boa tarde,

Tenho acesso limitado a internet e duas questões, agradeço desde já quem puder ajudar:

1) liguei agora para a AT, 217206707, teclas 1/5/3 e disseram me que nada mudou do lado deles, nem o certificado!? Para que número é que ligaram para obter informações + técnicas?

2) na minha aplicação .net, já tinha aquela linha ...ssl3 comentada há muito muito tempo e mesmo assim a aplicação não comunica guias. Há algo mais a fazer?

Desde já obrigado.

Boa tarde,

Obrigado ao Portelinha, brsqueiros e RikFonseca pelas sugestões.

No meu caso a aplicação de envio de guias (c# .net), é um programa à parte "add-on", isolado da aplicação principal (não .net) que só compilo ou actualizo "quando o rei faz anos" ou neste caso quando há problemas.

Aproveitei para actualizar a mesma que estava em VS2015 : target .net 3.5, para VS2017 : target .net 4.5 e passou a funcionar sem alterar qualquer linha no código ( não utilizava a linha "ServicePointMana ger.SecurityProtocol=..." , nem acrescentei "ServerCertificateValidationCallback=..."

O únicos problemas, por agora:
- há clientes (ainda) com XP que continuam com o problema. provavelmente devido ao .net 4.5 não parece ser compatível.
há alguém a comunicar guias (ainda) em XP? com o .net 4.5? ou conseguem enviar ainda com o .net 3.5?

- algumas máquinas com o Windows 10 Home, parecem estar com o mesmo problema. já tiveram estes problema?

Desde já obrigado, por qualquer sugestão.

 

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
RikFonseca
39 minutos atrás, antseq disse:

Boa tarde,

Obrigado ao Portelinha, brsqueiros e RikFonseca pelas sugestões.

No meu caso a aplicação de envio de guias (c# .net), é um programa à parte "add-on", isolado da aplicação principal (não .net) que só compilo ou actualizo "quando o rei faz anos" ou neste caso quando há problemas.

Aproveitei para actualizar a mesma que estava em VS2015 : target .net 3.5, para VS2017 : target .net 4.5 e passou a funcionar sem alterar qualquer linha no código ( não utilizava a linha "ServicePointMana ger.SecurityProtocol=..." , nem acrescentei "ServerCertificateValidationCallback=..."

O únicos problemas, por agora:
- há clientes (ainda) com XP que continuam com o problema. provavelmente devido ao .net 4.5 não parece ser compatível.
há alguém a comunicar guias (ainda) em XP? com o .net 4.5? ou conseguem enviar ainda com o .net 3.5?

- algumas máquinas com o Windows 10 Home, parecem estar com o mesmo problema. já tiveram estes problema?

Desde já obrigado, por qualquer sugestão.

 

Boa tarde,

Quando não definimos o SecurityProtocol, é utilizado o protocolo que estiver definido por defeito no Windows... O que tem sido alterado nos ultimos tempos através do Windows Update. Por isso, forcei a utilização de TLS 1.2.

O ServerCertificateValidationCallback serve para ignorar a validação do certificado remoto (o tal que foi alterado pela AT, cuja entidade emissora - COMODO - não consta nas entidades de certificação raiz). Se instalares o certificado em todas as máquinas, não é necessário estar a implementar isto...

Relativamente à framework, eu estou a utilizar a 3.5 (por isso tive de utilizar o valor 3072 em vez da constante por não existir), e só tive problemas com máquinas que não tinham updates em dia... o erro algo semelhante a: «could not load protocol»...

Não tenho a aplicação instalada em XP, mas como o XP não tem atualizações, pode não ter o protocolo instalado ou estar desativado no registry...

 

  • Voto 1

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
Hugo Costa
6 minutos atrás, RikFonseca disse:

Boa tarde,

Quando não definimos o SecurityProtocol, é utilizado o protocolo que estiver definido por defeito no Windows... O que tem sido alterado nos ultimos tempos através do Windows Update. Por isso, forcei a utilização de TLS 1.2.

O ServerCertificateValidationCallback serve para ignorar a validação do certificado remoto (o tal que foi alterado pela AT, cuja entidade emissora - COMODO - não consta nas entidades de certificação raiz). Se instalares o certificado em todas as máquinas, não é necessário estar a implementar isto...

Relativamente à framework, eu estou a utilizar a 3.5 (por isso tive de utilizar o valor 3072 em vez da constante por não existir), e só tive problemas com máquinas que não tinham updates em dia... o erro algo semelhante a: «could not load protocol»...

Não tenho a aplicação instalada em XP, mas como o XP não tem atualizações, pode não ter o protocolo instalado ou estar desativado no registry...

 

Boa tarde,

Completando a informação deixada pelo RikFonseca, o TLS 1.2 não é compatível com o Windows XP, como poderão ver no seguinte endereço:

https://blogs.msdn.microsoft.com/kaushal/2011/10/02/support-for-ssltls-protocols-on-windows/

Deixo aqui onde podem verificar em que atualização foi disponibilizado o novo protocolo e como ativar:

https://support.microsoft.com/en-us/help/4040243/how-to-enable-tls-1-2-for-configuration-manager

https://support.microsoft.com/en-us/help/3140245/update-to-enable-tls-1-1-and-tls-1-2-as-a-default-secure-protocols-in

 

  • Voto 1

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
antseq
Em 10/08/2018 às 14:57, Hugo Costa disse:

Boa tarde,

Completando a informação deixada pelo RikFonseca, o TLS 1.2 não é compatível com o Windows XP, como poderão ver no seguinte endereço:

https://blogs.msdn.microsoft.com/kaushal/2011/10/02/support-for-ssltls-protocols-on-windows/

Deixo aqui onde podem verificar em que atualização foi disponibilizado o novo protocolo e como ativar:

https://support.microsoft.com/en-us/help/4040243/how-to-enable-tls-1-2-for-configuration-manager

https://support.microsoft.com/en-us/help/3140245/update-to-enable-tls-1-1-and-tls-1-2-as-a-default-secure-protocols-in

 

Mais uma vez obrigado ao RikFonseca e Hugo Costa.

Voltei ao VS2015 +.net 3.5 e acrescentei estas linhas:

//Tls=192 | Tls11=768 | Tls12=3072
ServicePointManager.SecurityProtocol =
    SecurityProtocolType.Tls | (SecurityProtocolType)768 | (SecurityProtocolType)3072;
ServicePointManager.ServerCertificateValidationCallback += (sender, certificate, chain, sslPolicyErrors) => true;

Para já parece estar funcionar em + computadores (excepto XP) mesmo no Windows 10 Home que antes não funcionava.

(Em alternativa, ainda tenho a outra versão em VS2017 +.net 4.5 sem qualquer linha acrescentada)

Cumprimentos.

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites

Crie uma conta ou ligue-se para comentar

Só membros podem comentar

Criar nova conta

Registe para ter uma conta na nossa comunidade. É fácil!

Registar nova conta

Entra

Já tem conta? Inicie sessão aqui.

Entrar Agora

×

Aviso Sobre Cookies

Ao usar este site você aceita os nossos Termos de Uso e Política de Privacidade. Este site usa cookies para disponibilizar funcionalidades personalizadas. Para mais informações visite esta página.