marcolopes Posted January 2, 2025 at 05:08 PM Report #633916 Posted January 2, 2025 at 05:08 PM On 1/2/2025 at 5:01 PM, albertosilva said: Por curiosidade, o que tivemos de fazer foi precisamente criar um PEM em memória a partir do PFX, com a respetiva password, e depois realizar mais umas operações para instanciar o certificado a partir de uma exportação do PEM. No meu caso não necessito de efectuar qualquer conversão, pois o problema não está no certificado (talvez no vosso caso exista, porque o devem ter de "instalar" no sistema operativo, algo que eu não tenho de fazer, nem tal seria aceitável...) The simplest explanation is usually the correct one JAVA Utilities: https://github.com/marcolopes/dma
juliogut Posted January 2, 2025 at 05:08 PM Report #633917 Posted January 2, 2025 at 05:08 PM Em 02/01/2025 às 17:03, marcolopes disse: Eu, em ambiente de TESTES com JAVA 6 passei a ter o mesmo problema, como já aqui foi disctutido. Não consegui dar a volta, excepto actualizando para JAVA 8 (o que não pode acontecer no meu ambiente de TESTES) Como tal, e para evitar futuros problemas devido a mexidas pelo lado da AT, vou passar a basear o PROVIDER TLS nas LIBs da Bouncy Castle e não no JAVA NATIVO. NOTA: No meu caso o certificado de TESTES não é o problema... o problema é o HANDSHAKE que é feito pelo servidor, que exige uma CIFRA que agora não é suportada! (e não valeu de nada instalar o pack de cifras do JAVA 8, etc etc etc etc). Para mim o problema tem de ficar resolvido para que, de futuro, se a AT mudar o HANDSHAKE novamente, eu não fique dependente da versão do JAVA mas apenas de LIBs externas. Muito obrigado, vou tentar!
marcolopes Posted January 2, 2025 at 05:11 PM Report #633918 Posted January 2, 2025 at 05:11 PM (edited) On 1/2/2025 at 5:08 PM, juliogut said: Muito obrigado, vou tentar! Queria ter dito JAVA 7 (mas é quase irrelevante). A questão é que a AT alterou a CIFRA de HANDSHAKE TLS: https://stackoverflow.com/questions/18065170/how-do-i-do-tls-with-bouncycastle Como curiosidade, expus esta questão no e-Balcão, e recebi uma reposta com uma frase que nem vale a pena comentar... estamos entregues à "bicharada"... Edited January 2, 2025 at 05:12 PM by marcolopes The simplest explanation is usually the correct one JAVA Utilities: https://github.com/marcolopes/dma
Sergio. Posted January 2, 2025 at 06:57 PM Report #633919 Posted January 2, 2025 at 06:57 PM Em 02/01/2025 às 17:11, marcolopes disse: Queria ter dito JAVA 7 (mas é quase irrelevante). A questão é que a AT alterou a CIFRA de HANDSHAKE TLS: https://stackoverflow.com/questions/18065170/how-do-i-do-tls-with-bouncycastle Como curiosidade, expus esta questão no e-Balcão, e recebi uma reposta com uma frase que nem vale a pena comentar... estamos entregues à "bicharada"... - Pode-se afirmar que a AT vai parar a partir do dia 6 TODOS os clientes que não façam o HANDSHAKE com tls 1.2 ou superior? Quero ver isso xD - Até aqui não era preciso verificar a autenticidade a nível de https:// ao site da AT, antes de comunicar a guia, também vai passar a ser obrigatório? Também sei que vai entrar outras validações, nomeadamente nas guias à consignação... Fernando Pessoa: "Pensar é destruir. O pensamento é um parasita da consciência, uma doença da vontade."
marcolopes Posted January 2, 2025 at 07:20 PM Report #633920 Posted January 2, 2025 at 07:20 PM (edited) On 1/2/2025 at 6:57 PM, Sergio. said: - Pode-se afirmar que a AT vai parar a partir do dia 6 TODOS os clientes que não façam o HANDSHAKE com tls 1.2 ou superior? Quero ver isso xD - Até aqui não era preciso verificar a autenticidade a nível de https:// ao site da AT, antes de comunicar a guia, também vai passar a ser obrigatório? Também sei que vai entrar outras validações, nomeadamente nas guias à consignação... TLS 1.2 já era a bem dizer "obrigatório"... A autenticidade da ligação HTTP através de certificado poderá continuar até a ser facultativa (pelo sim pelo não convém estarmos preparados para tudo), mas, independentemente de assim ser ou não (eu ainda consigo o handshake através de uma "permissive store" - no fundo um "dummy certificate" que nada faz), o facto da implementação do HANDSHAKE pelo lado da AT ter alterado a CIFRA é suficiente para que qualquer tipo de HANDSHAKE falhe caso a CIFRA não esteja implementada do lado do "client" Em resumo... há aqui 2 (3?) problemas distintos! 1) O facto da AT vir a EXIGIR a utilização do CERTIFICADO SSL (já enviado por eles aos produtores) 2) O facto da AT ter ALTERADO a CIFRA utilizada para executar o HANDSHAKE (que já aconteceu há algumas semanas, pelo menos no ENDPOINT de testes) https://www.ibm.com/docs/en/cics-tg-multi/9.2?topic=java-ssl-cipher-suites-in-client-applications 3) O facto da AT exigir a utilização do protocolo TLS 1.2 (devido à falta de segurança dos protocolos anteriores a esta versão) - esta questão para mim era ponto assente, e todas as implementações deveriam já estar a utilizar TLS 1.2 https://www.ibm.com/docs/en/sdk-java-technology/8?topic=handshake-tls-12-protocol NOTA: A nível de implementação dos "clients" há que salientar que nem todas as implementações de TLS suportam "todas" as CIFRAS Pelo DEBUG do HANDSHAKE posso concluir que a CIFRA actual requerida pela implementação da AT é SHA256withRSA Found trusted certificate: Version: V3 Subject: CN=*.portaldasfinancas.gov.pt, O=Autoridade Tributária e Aduaneira, ST=Lisboa, C=PT Signature Algorithm: SHA256withRSA, OID = 1.2.840.113549.1.1.11 Key: Sun RSA public key, 2048 bits modulus: 23388950229064824724982467115156114221491407962862073819791386403993621467744762840532969871845717501511048802373853336366057265970709109067078823003750536007103687919955063390411431108132729398959110743371907042718357398836610701426597300762586579776398328774361072664820332811855667762351951116234180601279577331375379537489264916868969738750409831801082681304735406008164050610740624456418722823101245605238825246439260862060653800552155980088013403445180080889872252911572867308107975382188419562091501027394606407640750537756694738286448838872855586713701142398344033447802715568131246934721653054186158801370671 public exponent: 65537 Validity: [From: Wed Oct 16 01:00:00 BST 2024, To: Sat Nov 15 23:59:59 GMT 2025] Issuer: CN=Sectigo RSA Organization Validation Secure Server CA, O=Sectigo Limited, L=Salford, ST=Greater Manchester, C=GB SerialNumber: [ ed64d369 58a474e6 483a3299 b05b1c18] Edited January 2, 2025 at 07:49 PM by marcolopes The simplest explanation is usually the correct one JAVA Utilities: https://github.com/marcolopes/dma
juliogut Posted January 3, 2025 at 09:58 AM Report #633922 Posted January 3, 2025 at 09:58 AM Em 02/01/2025 às 19:20, marcolopes disse: TLS 1.2 was already "mandatory"... The authenticity of the HTTP connection through a certificate may continue to be optional (just in case we should be prepared for everything), but, regardless of whether this is the case or not (I can still get the handshake through a "permissive store" - basically a "dummy certificate" that does nothing), the fact that the implementation of the HANDSHAKE on the AT side has changed the CIFRA is enough for any type of HANDSHAKE to fail if the CIFRA is not implemented on the "client" side. In short... there are 2 (3?) distinct problems here! 1) The fact that AT will REQUIRE the use of the SSL CERTIFICATE (already sent by them to producers) 2) The fact that AT CHANGED the CIPHER used to execute the HANDSHAKE (which already happened a few weeks ago, at least in the test ENDPOINT) https://www.ibm.com/docs/en/cics-tg-multi/9.2?topic=java-ssl-cipher-suites-in-client-applications 3) The fact that AT requires the use of the TLS 1.2 protocol (due to the lack of security of protocols prior to this version) - this issue was a settled point for me, and all implementations should already be using TLS 1.2 https://www.ibm.com/docs/en/sdk-java-technology/8?topic=handshake-tls-12-protocol NOTE : At the level of "client" implementation, it should be noted that not all TLS implementations support "all" CIFFs. From the HANDSHAKE DEBUG I can conclude that the current CIPHER required by the AT implementation is SHA256withRSA E mais uma coisa, certo?: AT pede-nos para alterar a chave pública que utilizámos até agora (ChavePublicaAT.cer) para aqueles incluídos no e-mail (_.portaldasfinancas.gov.pt.p7b e portaldasfinancas.gov.pt.pem). E não acho que a mesma coisa que estávamos fazendo até agora vai funcionar, certo? Pelo menos no Android...
tikes Posted January 3, 2025 at 11:34 AM Report #633924 Posted January 3, 2025 at 11:34 AM Viva, não consigo também comunicar com os serviços de produção para registar séries com o erro "The request was aborted: Could not create SSL/TLS secure channel."; Estou a usar .Net 4.6.2 e inclusive coloquei a indicação para utuilizar o TLS 1.2, mas mesmo assim não funciona. Caso faça o pedido ao ambiente de testes funciona perfeitamente. Não recebi o email das finanças, existe lá alguma coisa que seja necessária? Pelos posts que li parece que não. Este é o código da minha função. public consultSeriesResp ConsultarSeries() { //Enable Tls 1.2 ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12; var utilizador = new UserSecurityV2().UtilizadorV2(userAt, passAt); var proxy = new SeriesWSService(); var certCollection = new X509Certificate2Collection(); certCollection.Import(NomeCertificado, PassCertificado, X509KeyStorageFlags.DefaultKeySet); foreach (var crt in certCollection) { proxy.ClientCertificates.Add(crt); } proxy.Url = ProductionEndpoint; proxy.SecurityToken = utilizador; try { var resultado = proxy.consultarSeries(); return resultado; } catch (Exception ex) { return null; } } Alguém conseguiu contornar? Obrigado
furiousangelpt Posted January 3, 2025 at 12:34 PM Report #633926 Posted January 3, 2025 at 12:34 PM Mesmo problema, vou ver se nas guias tem o mesmo problema.
furiousangelpt Posted January 3, 2025 at 02:19 PM Report #633927 Posted January 3, 2025 at 02:19 PM Acho que tem haver com o PFX, o meu expirou em Março de 2023, alguém tem a versão mais recente?
abrito Posted January 3, 2025 at 02:33 PM Report #633928 Posted January 3, 2025 at 02:33 PM (edited) Isto é mesmo muito interessante. depois de varias post sobre o assunto anteriormente e de a maior parte dos problemas estarem documentados nos posts anteriores, aparecem aqui uns passarinhos com uns problemas que já foram reportados, resolvidos, na totalidade, "pelo que me apercebi" e nem se dão ao trablho de ler posts anteriores sobre o assunto. Devem estar a espera que voltem a postar só porque os meninos tem o problema e querem que o resolva. A programação em Portugal assim vai de mal a pior. Por favor parem de colocar problemas repetidos e procurem as soluções nos posts anteriores. Estes teenagers precisavam de levar umas palmadas no rabiosque. :) :) :) :) . Mas só para vos aliviar um pouco a mente, vou vos reportar o seguinte. Tanto o endpoint de testes como o endpoint de produção estão a funcionar a 100% a data de 03-01-2025 14:42.00. isto quer dizer que o problema esta do vosso lado. :) :) :) :) :). Edited January 3, 2025 at 02:43 PM by abrito
furiousangelpt Posted January 3, 2025 at 04:00 PM Report #633929 Posted January 3, 2025 at 04:00 PM Comentários como "Portugal assim vai de mal a pior" não ajuda e em vez de reclamar/criticar, ajuda-se a resolver era bem melhor. Sim, sei que o problema é do meu lado, sim, vi a conversa que estava aqui no tópico, sim atualizei os certificados, e sim continuo com o mesmo problema! Continuo a não ver onde esta o problema.
tikes Posted January 3, 2025 at 04:50 PM Report #633931 Posted January 3, 2025 at 04:50 PM O problema do meu lado era o certificado pfx que estava caducado. Foi necessário fazer o pedido de um novo no e-fatura. Este é valido até 28-06-2025, nessa altura como já falado tudo vai caducar. Relativamente ao membro @abrito, obrigado pela ajuda e para retribuir e fomentar a entreajuda deste fórum, renove o certificado ssl do seu site. @furiousangelpt se precisares de alguma ajuda força. Obrigado 1 Report
abrito Posted January 3, 2025 at 05:15 PM Report #633932 Posted January 3, 2025 at 05:15 PM Em 03/01/2025 às 16:50, tikes disse: O problema do meu lado era o certificado pfx que estava caducado. Foi necessário fazer o pedido de um novo no e-fatura. Este é valido até 28-06-2025, nessa altura como já falado tudo vai caducar. Relativamente ao membro @abrito, obrigado pela ajuda e para retribuir e fomentar a entreajuda deste fórum, renove o certificado ssl do seu site. @furiousangelpt se precisares de alguma ajuda força. Obrigado @tikes o certificado do meu site não tem problema nenhum valido até Sat, 15 Feb 2025 08:55:25 GMT até porque não sou eu que o valido e sim o provedor hummmmmmmmmm. será que não estas com problemas de data no computador ou no teu browser. hummmmmm. quanto á minha ajuda se tivesses lido os posts anteriores tinhas encontrado a resposta ao teu problema. Isso ja foi discutido a muitos dias atras. E depois de no inicio de Dezembro a AT enviar o Email para testar atempadamente as alterações no endpoint de testes, tu vens para aqui no dia 03-01-2025 procurar ajuda ou seja nos ultimos dias e que reparaste que poderias ter problemas na comunicação. Só esbarraste foi ao comunicar as series que deixou de funcionar , tu não ligaste patavina ao email que a AT enviou. Pensaste logo se vê o que vai dar no forum eles resolvem e depois eu vejo o que fazer. Quando estais com as calças na mão vêm para aqui pedir entreajuda e tal ou coisa que o pareça. PREGUIÇOSOS, PREGUIÇOSOS, PREGUIÇOSOS, PREGUIÇOSOS. BOM ANO.
furiousangelpt Posted January 3, 2025 at 07:11 PM Report #633934 Posted January 3, 2025 at 07:11 PM A hora esta certa, os certificados estão atualizados, tem a atualização do código para utilizar o TLS v1.2, o sistema é Win. 10. Falta mais alguma coisa?
marcolopes Posted January 3, 2025 at 07:54 PM Report #633935 Posted January 3, 2025 at 07:54 PM (edited) On 1/3/2025 at 4:50 PM, tikes said: O problema do meu lado era o certificado pfx que estava caducado. Foi necessário fazer o pedido de um novo no e-fatura. Este é valido até 28-06-2025, nessa altura como já falado tudo vai caducar. Relativamente ao membro @abrito, obrigado pela ajuda e para retribuir e fomentar a entreajuda deste fórum, renove o certificado ssl do seu site. @furiousangelpt se precisares de alguma ajuda força. Obrigado PFX, JKS, etc... isso não indica QUAL é o certificado! Temos: 1) CHAVE PÚBLICA da AT! (emitida e actualizada pela AT) 2) Certificado do PRODUTOR de SOFTWARE (emitido pela AT a pedido do PRODUTOR) 3) Certificado de TESTES (emitido e actualizado pela AT - alternativa ao certificado do PRODUTOR para a finalidade de TESTES) O FORMATO em que os certificados estão é completamente irrelevante. Edited January 3, 2025 at 07:54 PM by marcolopes The simplest explanation is usually the correct one JAVA Utilities: https://github.com/marcolopes/dma
abrito Posted January 4, 2025 at 09:33 AM Report #633937 Posted January 4, 2025 at 09:33 AM Em 03/01/2025 às 19:11, furiousangelpt disse: A hora esta certa, os certificados estão atualizados, tem a atualização do código para utilizar o TLS v1.2, o sistema é Win. 10. Falta mais alguma coisa? Qual é o erro que estas a receber?
furiousangelpt Posted January 4, 2025 at 09:48 AM Report #633938 Posted January 4, 2025 at 09:48 AM O erro que estou a receber é "Pedido abortado: Não foi possível criar um canal seguro SSL/TLS."
abrito Posted January 4, 2025 at 10:11 AM Report #633939 Posted January 4, 2025 at 10:11 AM Em 04/01/2025 às 09:48, furiousangelpt disse: O erro que estou a receber é "Pedido abortado: Não foi possível criar um canal seguro SSL/TLS." https://ajuda.vendaerp.com.br/conhecimento-geral/nao-foi-possivel-criar-um-canal-seguro-para-ssl-tls
furiousangelpt Posted January 4, 2025 at 10:49 AM Report #633940 Posted January 4, 2025 at 10:49 AM segui todos os passos exceto a instalação dos certificados. Agora o VS não consegue ligar a canais seguros. É necessário instalar os certificados?
fakada Posted January 4, 2025 at 11:57 AM Report #633941 Posted January 4, 2025 at 11:57 AM (edited) Bom dia, Estou a tentar reimplementar uma biblioteca para comunicaçao das guias de transporte mas estou com problemas a comunicar com o servidor de testes. Basicamente dá-me timeout. Failed to open TCP connection to servicos.portaldasfinancas.gov.pt:701 O endpoint que estou a usar é este: https://servicos.portaldasfinancas.gov.pt:701/sgdtws/documentosTransporte/ O PFX que estou a usar é : openssl pkcs12 -in certs/testes/2024/TesteWebservices.pfx -clcerts -nokeys -out - | openssl x509 -text -noout Enter Import Password: Certificate: Data: Version: 3 (0x2) Serial Number: 15:00:00:00:f1:4a:fc:20:9a:15:45:8d:ed:00:00:00:00:00:f1 Signature Algorithm: sha256WithRSAEncryption Issuer: C = PT, L = Lisboa, O = Autoridade Tributaria e Aduaneira, CN = AT Issuing CA1 Validity Not Before: Aug 13 16:18:41 2024 GMT Not After : Feb 9 16:18:41 2025 GMT Subject: C = PT, ST = Lisboa, L = Lisboa, O = Autoridade Tributaria e Aduaneira, OU = Sistemas de Informacao, CN = TesteWebservices Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (4096 bit) Modulus: 00:ad:5c:c2:9e:29:47:10:4d:08:28:3a:9c:53:e1: .... .... Como isto é em Ruby estou a usar Savon. Para dar mais contexto: # Initialize Savon client with the correct SSL options and WSDL path client = Savon.client( wsdl: wsdl_uri, env_namespace: :S, convert_request_keys_to: :camelcase, log: true, # Enable logging log_level: :debug, # Set desired log level pretty_print_xml: true, # Pretty-print XML for readability read_timeout: @config.read_timeout, open_timeout: @config.open_timeout, ssl_cert_file: cert_temp.path, # Path to client certificate ssl_cert_key_file: key_temp.path, # Path to SSL private key ssl_ca_cert_file: ca_temp.path, # Path to CA certificates ssl_verify_mode: :peer, # Ensure SSL verification is enabled ssl_version: :TLSv1_2 # Specify TLS version as needed ) O que é que pode estar a falhar do meu lado ? Obrigado Fabio Edited January 4, 2025 at 12:00 PM by fakada
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now