Utilizar Webservices da AT

[nunopicado]

Em 09/01/2025 às 14:40, Cu5co disse:

Houve mesmo um comunicado por parte da AT?? Se sim, conseguem passar-me o link deste comunicado, please??!!!!!!!

Acho que só houve um mail no inicio de Dezembro.
Pelo menos eu só recebi isso.

[jasb]

Em 09/01/2025 às 15:44, Serafim Folha disse:

Boa tarde,

Alguem que utilize PHP ainda tem problemas em comunicar? Mesmo forçando  o TLS 1.2 no request e o openssl tem suporte para ele no SO continua-me a dar erro

Obrigado. 

o teu caso eh diff.. é caso para dizer que te fizeram a folha!

tens de ter o openssl ou gnutls (depende como isso estiver) actualizado

[karlynhuz]

On 1/9/2025 at 4:51 PM, CCoutinho said:

Vê o post do @americob em https://www.portugal-a-programar.pt/forums/topic/57734-utilizar-webservices-da-at/page/36/#findComment-502844

Se continuar com erro, confirma o .LastErrorTxt ou .LastErrorXML do Chilkat

Problema ultrapassado. Com a grande ajuda do colega @1000s. O problema do erro 33 no nosso caso tinha a ver com a encriptação dos dados no header do soap request que, com a atualização dos componentes Chilkat da versão 3 para a 10 (!!!), passou a ser feito de forma diferente. O nosso sistema velhinho (em Delphi 6) já comunica em todos os SO testados (11, 10 e XP!). Força aí para quem ainda não conseguiu. 

[karlynhuz]

On 1/9/2025 at 5:40 PM, nunopicado said:

Acho que só houve um mail no inicio de Dezembro.
Pelo menos eu só recebi isso.

Nós também recebemos apenas o tal email de 9 de dezembro mas não dê-mos a devida importância porque parecia ser apenas mais um email dos que já fomos recebendo outros anos acerca da atualização do certificado SSL do site e que não afeta praticamente ninguém. A parte menos importante vinha realçada a texto azul. E no fim da mensagem tem lá então uma frase acerca do TLS 1.2... que nos passou ao lado. Mas honestamente, mensagem a 9 de dezembro para entrar em ação a 6 de janeiro... não sei da vida dos outros mas eu gosto de férias e com o Natal e passagem de ano a meio da semana, não me parece ser um prazo de tempo aceitável. Enfim. É o que temos e provavelmente o que merecemos. 

[1000s]

Em 09/01/2025 às 18:22, karlynhuz disse:

Nós também recebemos apenas o tal email de 9 de dezembro mas não dê-mos a devida importância porque parecia ser apenas mais um email dos que já fomos recebendo outros anos acerca da atualização do certificado SSL do site e que não afeta praticamente ninguém. A parte menos importante vinha realçada a texto azul. E no fim da mensagem tem lá então uma frase acerca do TLS 1.2... que nos passou ao lado. Mas honestamente, mensagem a 9 de dezembro para entrar em ação a 6 de janeiro... não sei da vida dos outros mas eu gosto de férias e com o Natal e passagem de ano a meio da semana, não me parece ser um prazo de tempo aceitável. Enfim. É o que temos e provavelmente o que merecemos. 

Sage devia estar a precisar de faturar...

[marcolopes]

On 1/9/2025 at 2:40 PM, Cu5co said:

Houve mesmo um comunicado por parte da AT?? Se sim, conseguem passar-me o link deste comunicado, please??!!!!!!!

Again??? TLS 1.1 e CIFRAS FRACAS não suportadas a partir de 6 de Janeiro. (é CERTO que só esta alteração deveria merecer um EMAIL com assunto próprio, o que não aconteceu)

Quote

Em complemento, como parte de nossos esforços contínuos para manter a integridade e a segurança dos dados transmitidos pelos serviços que disponibilizamos, estamos a desativar cifras SSL/TLS fracas, tais como RC4, DES, e SSLv3, que estão associadas a vulnerabilidades conhecidas.

Numa primeira fase, esta alteração foi efetuada em ambiente de qualidade. Certifique-se de que os seus sistemas, servidores e navegadores estão configurados para suportar protocolos mais seguros, como TLS 1.2 e TLS 1.3.

 Esta alteração será efetuada em ambiente de produção em 06 de Janeiro de 2025.

Quote

Assunto:Renovação do certificado "SSL" - servicos.portaldasfinancas.gov.pt

Data:Mon, 9 Dec 2024 10:43:32 +0000

De:ASI - Certificados Digitais <asi-cd@at.gov.pt>

Exmos Senhores 

 O certificado digital de SSL do sítio servicos.portaldasfinancas.gov.pt (portos 4XX,5XX) irá expirar brevemente e, por isso, irá ser alterado, em ambiente de produção, no próximo dia 06 de Janeiro, da parte da manhã.

 Esta alteração implica a substituição do certificado digital de SSL e respetiva cadeia de certificação. 

 Recomendamos que testem os vossos produtos para que não haja problemas na comunicação, designadamente de Documentos de Transporte, Faturas, Declarações de IRC, Contratos de Arrendamento, ICS, ECS, SICEX, SICEU para a AT por parte dos operadores económicos vossos clientes. 

 Para tal, a AT vai alterar hoje certificado SSL nos portos de testes (7XX, 8XX) para que cada produtor de software/operador económico possa testar a continuidade do funcionamento dos seus produtos, contendo já estes endereços o novo certificado SSL.

 Recomendamos que se valide a cadeia de certificação, conforme o exemplo indicado no “Código Fonte da aplicação em Java Applet”, o qual pode ser obtido através da ligação: https://faturas.portaldasfinancas.gov.pt/testarLigacaoWebService.action

 O ficheiro enviado em anexo contém no seu interior as chaves públicas do novo certificado digital SSL e as chaves públicas da cadeia de certificação, no formato “.p7b” e formato “.pem”. Estas chaves públicas são apenas  utilizadas no estabelecimento da ligação SSL entre os sistemas dos clientes dos WebServices e a AT. 

 Os pedidos de esclarecimento deverão ser colocados ao e-balcão através do site do portal das finanças.

  A chave para abrir o ficheiro anexo é: PORTAL2025

 Em complemento, como parte de nossos esforços contínuos para manter a integridade e a segurança dos dados transmitidos pelos serviços que disponibilizamos, estamos a desativar cifras SSL/TLS fracas, tais como RC4, DES, e SSLv3, que estão associadas a vulnerabilidades conhecidas.

Numa primeira fase, esta alteração foi efetuada em ambiente de qualidade. Certifique-se de que os seus sistemas, servidores e navegadores estão configurados para suportar protocolos mais seguros, como TLS 1.2 e TLS 1.3.

  Verifique os certificados SSL/TLS utilizados e as configurações de segurança no seu ambiente para garantir a conformidade.

  Esta alteração será efetuada em ambiente de produção em 06 de Janeiro de 2025.

  Na esperança de poder contribuir para o seu esclarecimento, enviamos-lhes os melhores cumprimentos,

José Manuel Oliveira

Autoridade Tributária e Aduaneira

ASI - Certificados Digitais
Av. Eng. Duarte Pacheco, nº 28 - 15º - 1099-013 Lisboa
Geral: (+351) 213 834 200 - Fax: (+351) 213 834 974
CAT - Centro de atendimento telefónico - (+351) 217 206 707
E-mail: asi-cd@at.gov.pt Visite-nos em www.portaldasfinancas.gov.pt

Edited January 9, 2025 at 08:04 PM by marcolopes

[jasb]

Em 09/01/2025 às 20:01, marcolopes disse:

Again??? TLS 1.1 e CIFRAS FRACAS não suportadas a partir de 6 de Janeiro. (é CERTO que só esta alteração deveria merecer um EMAIL com assunto próprio, o que não aconteceu)

que cena, de facto isso foi enviado no email, eu nem reparei,

como vem na parte de baixo nas letras com outro formato e côr, ate pensei que fosse o disclaimer nem li!!

[josebarata]

Em 09/01/2025 às 11:29, 1000s disse:

Finalmente a funcionar Windows 7 e Vb6

estou com o velhinho vb6 e chilkat 10 ainda em testes, não podias enviar um exemplo. utilizava o antigo chilkat mas deixou de funcionar. obrigado

Edited January 9, 2025 at 09:32 PM by josebarata

[josebarata]

Em 08/01/2025 às 12:37, karlynhuz disse:

E consegues comunicar? Estou com Chilkat e não passo do erro 33 nas guais. Na webservice das séries em ambiente de teste dá o erro 118. Ambos erros de autenticação. 

Boas, estou com o mesmo erro, já tem solução?

[josebarata]

Em 11/04/2013 às 17:50, americob disse:

Assim de repente, vejo que estás a usar o LitlleEndien a 0 e no meu está a 1 (eu passei umas semanas de volta disso quando foi das faturas).

 

lorsa.Charset = "utf-8"
loRsa.EncodingMode = "base64"
loRsa.LittleEndian = 1
lorsa.VerboseLogging = 1
lorsa.OaepPadding = 0
locrypt.VerboseLogging = 1
loCrypt.CryptAlgorithm = "aes"
loCrypt.CipherMode = "ebc"
loCrypt.KeyLength = 128
loCrypt.CharSet = "utf-8"
loCrypt.PaddingScheme = 0
loCrypt.EncodingMode = "base64"

 

Cumptos,

estou com o mesmo problema, mas qual foi a alteração que fizeste para dar?

[karlynhuz]

Em 10/01/2025 às 02:29, josebarata disse:

Boas, estou com o mesmo erro, já tem solução?

No nosso caso foi só mudar rsa.LittleEndian de 1 para 0 e deixou de dar o erro 33 e comunica sem problemas:

rsa.LittleEndian := 0;

Na versão 3 do Chilkat funcionava com LittleEndian = 1 mas agora na versão 10 tem que estar a 0. 

Citação

In earlier versions of the Chilkat library, such as version 3, the LittleEndian property in the RSA component controlled the byte order for encryption and decryption operations. Setting rsa.LittleEndian := 1; enabled little-endian byte ordering, which was necessary for compatibility with certain systems or protocols.

However, starting from version 9.5.0.49, Chilkat made a significant change to the behavior of the LittleEndian property for encryption and decryption. The interpretation of this property was reversed to align with standard conventions. As a result, the same setting that previously enabled little-endian byte ordering now enables big-endian byte ordering, and vice versa.

This change means that if your application explicitly set the LittleEndian property in earlier versions, you would need to reverse its setting when updating to version 9.5.0.49 or later, but only for encryption and decryption operations. No changes are required if you are performing signature creation or verification.

[americob]

Em 10/01/2025 às 02:56, josebarata disse:

estou com o mesmo problema, mas qual foi a alteração que fizeste para dar?

Em 10/01/2025 às 11:21, karlynhuz disse:

No nosso caso foi só mudar rsa.LittleEndian de 1 para 0 e deixou de dar o erro 33 e comunica sem problemas:

rsa.LittleEndian := 0;

Na versão 3 do Chilkat funcionava com LittleEndian = 1 mas, por motivos que agora não tenho tempo para investigar, agora na versão 10 tem que estar a 0. 

Essa menssagem, que escrevi em 11/04/2013, era como funcionava na altura.

Entretanto, alguns anos mais tarde, a Chilkat reconheceu que estava a interpretar esse parametro ao contrário e inverteu. Acho que o fez por volta da versão 9.5.0_50, isto é à meia duzia de anos.

[sergiosmvc]

Em 10/01/2025 às 11:35, americob disse:

Essa menssagem, que escrevi em 11/04/2013, era como funcionava na altura.

Entretanto, alguns anos mais tarde, a Chilkat reconheceu que estava a interpretar esse parametro ao contrário e inverteu. Acho que o fez por volta da versão 9.5.0_50, isto é à meia duzia de anos.

Agora vem os engraçadinhos dizer: blablabla n devias ter usado chilkat devias ter feito tu em c++ ou mesmo em assembly a tua biblioteca de comunicação http
pq assim ficas sempre dependente do que os malucos do chillkat mudarem...

[josebarata]

Em 10/01/2025 às 10:35, americob disse:

Essa menssagem, que escrevi em 11/04/2013, era como funcionava na altura.

Entretanto, alguns anos mais tarde, a Chilkat reconheceu que estava a interpretar esse parametro ao contrário e inverteu. Acho que o fez por volta da versão 9.5.0_50, isto é à meia duzia de anos.

 

é mesmo isso, muito obrigado. 

Já agora para ajudar quem tinha o antigo chilkat, o que alterei para o novo chilkat10 foi: 

.littleEndian = 1  para 0   como foi referido anteriormente.

e

    'Http.SetSslClientCertPfx App.Path + "\WebService2014.pfx", "4354543554545", "" ' CERTIFICADO DE PRODUÇÃO

para
    sucess = Http.SetSslClientCertPfx(App.Path + "\WebService2014.pfx", "4354543554545")

 

boa sorte para todos!

[bioshock]

On 1/9/2025 at 3:44 PM, Serafim Folha said:

Boa tarde,

Alguem que utilize PHP ainda tem problemas em comunicar? Mesmo forçando  o TLS 1.2 no request e o openssl tem suporte para ele no SO continua-me a dar erro

Obrigado. 

On 1/9/2025 at 6:12 PM, jasb said:

o teu caso eh diff.. é caso para dizer que te fizeram a folha!

tens de ter o openssl ou gnutls (depende como isso estiver) actualizado

Não encontro problemas, nem tão pouco tive de actualizar o código. O cURL já establece a ligação com o melhor protocolo do servidor (v1.3 TLS).
 

[jasb]

Em 12/01/2025 às 03:25, bioshock disse:

Não encontro problemas, nem tão pouco tive de actualizar o código. O cURL já establece a ligação com o melhor protocolo do servidor (v1.3 TLS).
 

porque tens as libs actualizadas né! ele pelos vistos não,

[trs80]

On 1/8/2025 at 10:19 AM, Sergio. said:

Bom dia,
As únicas informações é as datas dos certificados de raiz da AT a terminarem a 28/6, até aqui tudo normal. Já aconteceu no passado.
O que já acho estranho é que qualquer pedido de renovação dos certificados das casas de software que era de 2 anos, nos últimos tempos tem vindo com o numero de dias exatos até 28/6 também. Esta questão aqui é que não é normal, mais de 3000 certificados vão ter que ser renovados, pergunto qual o motivo para terem TODOS na mesma altura.
Por natureza a minha velhice desconfia destes atos inocentes....mas como alguém já disse pode não ser nada.

Não sou perito mas penso  (se alguem puder confirmar ou negar seria optimo):

1 - Os nossos certificados sao assinados pelo intermedio que é assinado pelo root. O root termina em 28/6 e portanto o intermediate tambem, dai os nossos tambem terminem em 28/6.

2 - Isso não deveria ser impeditivo de já terem o novo root e intermediate e fornecerem a partir dai aos novos pedidos.

Tanto quanto sei não existe qualquer obrigatoriedade de ambos os lados validarem com a mesma chain e root e não deveria haver nenhum problema em terem duas chains no lado deles para validar o nosso certificado ... mas talvez isso implicasse alterações que eles nao querem fazer e vao optar por trocar a chain no dia 28.

Isso irá obrigar a alterações do software cliente, eg if data >28 / 6 then new else old

3 - Quanto ao outro aspecto de usar ou nao a chain publica fornecida, pelo menos no meu software estou a confiar no certificado que a AT manda (ie nao estou a validar com a chain)

4 - (unrelated) Já agora quanto à chave privada para assinatura do HASHs dos documentos:

Apesar de nao ter, tecnicamente, validade é fraca (1024 bits), já procurei na minha documentação mas não encontro nada sobre validades. alguem faz ideia se pode ser usada ad eternum ?

[CPHJ1966]

Ainda não percebi a razão de estarem a enviar os certificados com data até 28/06, pois no passado o certificado ChavePublica mudou e nunca se colocou esta questão.

Cheira-me a esturro. A AT deve estar a preparar alguma surpresa.

[josalm]

Acho que vocês vêm muitos filmes. Só teorias da conspiração ahah

[americob]

Em 12/01/2025 às 15:51, trs80 disse:

4 - (unrelated) Já agora quanto à chave privada para assinatura do HASHs dos documentos:

Apesar de nao ter, tecnicamente, validade é fraca (1024 bits), já procurei na minha documentação mas não encontro nada sobre validades. alguem faz ideia se pode ser usada ad eternum ?

A versão da chave é a apresentada na Modelo 24.

Quando fizemos a certificação, informaram-nos que deveriamos apresentar uma nova chave quando a segurança da anterior ficasse comprometida.