Jump to content

Recommended Posts

Posted
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

Posted
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!

Posted (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 by marcolopes

The simplest explanation is usually the correct one

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

Posted
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."

Posted (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 by marcolopes

The simplest explanation is usually the correct one

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

Posted
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...

Posted

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

Posted (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 by abrito
Posted

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. 

Posted

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

  • Vote 1
Posted
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. 

Posted (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 by marcolopes

The simplest explanation is usually the correct one

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

Posted
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?

Posted (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 by fakada

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.