Utilizar Webservices da AT

[123xyz]

Em 02/04/2025 às 23:02, marcolopes disse:

Só faltava agora sermos obrigados a REDUZIR a informação constante dos campos do CSR para não ultrapassar esse valor MÁXIMO que estão a indicar!!!

Esse valor máximo é STARNDARD para os pedidos CSR? Ainda não investiguei...

Por acaso até experimentei isso e reduzi a informação e certificado a 1708 carateres, e deu à mesmo ao erro de 1722 carateres... LOL

Ou seja, até têm um bug na validação do tamanho no e-fatura. NOOBICE TOTAL!

[mganilho]

Em 06/04/2025 às 12:31, desconfiado disse:

Só uma duvida, se a chave vai ter que alterar, então vai ser necessário reiniciar todas as séries. Porque a assinatura vai ser feita com uma chave diferente e isso não é permitido pois tornaria impossível a validação das hash dos documentos dentro das séries.

Ou estou a ver mal a coisa?

 

PS: Isto vai ser um "caos" total com os clientes e deveria ser dados mais tempo para isto.

@desconfiado ao contrário do que alguns disseram, a tua questão parece-me pertinente (obrigado por nos fazeres pensar). Contudo, há um pequeno pormenor que resolve o problema e que creio que não estás a considerar.
O que estás a ver bem:

• habitualmente quando pedimos um novo certificado não estamos a especificar uma nova chave privada. Fazemos um novo pedido CSR, mas a chave permanece a mesma. Geralmente, apenas existe razão para alterar a chave privada, se esta for comprometida e existir receio que seja conhecida de terceiros. Ou seja, mudar de certificado não é realmente o mesmo que mudar de chave privada.
• agora foi solicitado que se utilize uma chave privada com uma nova dimensão, o que obrigatoriamente conduz a uma nova chave privada e a uma respectiva chave pública,, caso atípico para o que costumamos fazer.
• quando assinamos utilizamos o HASH do documento anterior da série

O que creio que estás a esquecer:

• quando submetemos um pedido de certificado, especificamos também à AT qual a versão da chave (número inteiro sequencial)
• quando assinamos um documento preenchemos a Hash e também colocamos essa versão no HashControl da chave que utilizámos 
• quando iniciamos e comunicamos uma série, não a associamos a nenhuma versão de chave privada.

Assim, parece-me que ao mudar a versão de uma chave podemos continuar a assinar documentos dentro de uma série que já possui documentos assinados com uma chave de versão anterior. No SAFT, para além do Hash, também é comunicado o HashControl. Por isso, a AT tem forma de saber a versão da chave privada que foi utilizada para assinar cada documento, podendo por isso utilizar o par respectivo da chave pública que nós lhe comunicámos.
 

Parece-me que estarei a relacionar os conceitos de forma correcta. Se alguém discordar, tinha muito interesse em o ouvir.
 

Edited April 8, 2025 at 05:08 PM by mganilho

[Tiagoinf]

Boa tarde,

Tenho o meu cert.pem que expira em Apr 13 10:26:22 2025.

O que devo fazer? Gerar o csr em 4096 e enviar para a AT?

 

Obrigado

[Sergio.]

Em 08/04/2025 às 18:07, mganilho disse:

habitualmente quando pedimos um novo certificado não estamos a especificar uma nova chave privada. Fazemos um novo pedido CSR, mas a chave permanece a mesma. Geralmente, apenas existe razão para alterar a chave privada, se esta for comprometida e existir receio que seja conhecida de terceiros. Ou seja, mudar de certificado não é realmente o mesmo que mudar de chave privada.

A resposta correta é: Fazer como está no manual
Problema: O manual não foi alterado.
Conclusão: é à vontade do freguês.😂

Agora na teoria, nada no manual diz que não se pode ter a chave privada antiga para o HASH e fazer outra só para o CSR certo?
Mas como digo nada como seguir o manual. 🙂

Mas acredito que não seja preciso criar uma chave privada para o efeito, não sei o motivo que levou a AT a dar essa solução... eu quando o site estive a funcionar irei fazer como está no manual com a alteração de 2048 para 4096.

Edited April 8, 2025 at 05:46 PM by Sergio.
sintax

[marcolopes]

On 4/8/2025 at 6:07 PM, mganilho said:

@desconfiado ao contrário do que alguns disseram, a tua questão parece-me pertinente (obrigado por nos fazeres pensar). Contudo, há um pequeno pormenor que resolve o problema e que creio que não estás a considerar.
O que estás a ver bem:

• habitualmente quando pedimos um novo certificado não estamos a especificar uma nova chave privada. Fazemos um novo pedido CSR, mas a chave permanece a mesma. Geralmente, apenas existe razão para alterar a chave privada, se esta for comprometida e existir receio que seja conhecida de terceiros. Ou seja, mudar de certificado não é realmente o mesmo que mudar de chave privada.
• agora foi solicitado que se utilize uma chave privada com uma nova dimensão, o que obrigatoriamente conduz a uma nova chave privada e a uma respectiva chave pública,, caso atípico para o que costumamos fazer.
• quando assinamos utilizamos o HASH do documento anterior da série

O que creio que estás a esquecer:

• quando submetemos um pedido de certificado, especificamos também à AT qual a versão da chave (número inteiro sequencial)
• quando assinamos um documento preenchemos a Hash e também colocamos essa versão no HashControl da chave que utilizámos 
• quando iniciamos e comunicamos uma série, não a associamos a nenhuma versão de chave privada.

Assim, parece-me que ao mudar a versão de uma chave podemos continuar a assinar documentos dentro de uma série que já possui documentos assinados com uma chave de versão anterior. No SAFT, para além do Hash, também é comunicado o HashControl. Por isso, a AT tem forma de saber a versão da chave privada que foi utilizada para assinar cada documento, podendo por isso utilizar o par respectivo da chave pública que nós lhe comunicámos.

Parece-me que estarei a relacionar os conceitos de forma correcta. Se alguém discordar, tinha muito interesse em o ouvir.

"habitualmente quando pedimos um novo certificado não estamos a especificar uma nova chave privada. Fazemos um novo pedido CSR, mas a chave permanece a mesma."

Só se fores tu... Eu quando peço um NOVO certificado através de um CSR (Certificate Signing Request) crio SEMPRE UMA NOVA CHAVE PRIVADA RSA 2048 bits! (e porque não o haveria de fazer?? se é um NOVO certificado, eu posso decidir mudar a chave privada... até porque pode ter sido comprometida, etc etc)

Não muda nada... excepto a segurança da CHAVE RSA, que passa a 4096 bits!

Não vejo qual seja o drama...

Em RESUMO: quem está a pedir um certificado através de um CSR criado SEMPRE com a mesma chave privada, pode muito bem gerar uma NOVA chave privada que tal não vai afectar o que quer que seja!!

Edited April 8, 2025 at 05:57 PM by marcolopes

[marcolopes]

On 4/4/2025 at 6:29 PM, CPHJ1966 said:

Passos a seguir de acordo com a AT:

* Geração da chave privada RSA 4096 bits:

   openssl genrsa -out [NIF].key 4096

* Criação do CSR com assinatura SHA-256

   openssl req -new -key [NIF].key -out [NIF].csr -sha256 -subj "/C=[País]/ST=[Distrito]/L=[Local]/O=[Designação] /OU=[Departamento]/CN=[NIF]/emailAddress=[Email]"

O ficheiro .CSR será enviado à AT para criação do certificado digital.

Por acaso não uso essa técnica... faço tudo num único passo...

set OPENSSL_SUBJ=
set OPENSSL_SUBJ=%OPENSSL_SUBJ%/CN=NIF da entidade aderente (9 chars)
set OPENSSL_SUBJ=%OPENSSL_SUBJ%/ST=Distrito da sede (32 chars)
set OPENSSL_SUBJ=%OPENSSL_SUBJ%/L=Local da sede (32 chars)
set OPENSSL_SUBJ=%OPENSSL_SUBJ%/C=Codigo ISO referente ao PAIS da sede (2 chars)
set OPENSSL_SUBJ=%OPENSSL_SUBJ%/O=Designacao legal da empresa (180 chars)
set OPENSSL_SUBJ=%OPENSSL_SUBJ%/OU=Departamento para contacto (180 chars)
set OPENSSL_SUBJ=%OPENSSL_SUBJ%/emailAddress=Endereco de correio eletronico (80 chars)

//GERA O CSR (Certificate Signing Request) E UMA CHAVE PRIVADA RSA 2048
openssl req -new -subj "%OPENSSL_SUBJ%" -newkey rsa:2048 -nodes -keyout 999999990.key > 999999990.csr

 

[mganilho]

Em 08/04/2025 às 18:56, marcolopes disse:

"habitualmente quando pedimos um novo certificado não estamos a especificar uma nova chave privada. Fazemos um novo pedido CSR, mas a chave permanece a mesma."

Só se fores tu... Eu quando peço um NOVO certificado através de um CSR (Certificate Signing Request) crio SEMPRE UMA NOVA CHAVE PRIVADA RSA 2048 bits! (e porque não o haveria de fazer?? se é um NOVO certificado, eu posso decidir mudar a chave privada... até porque pode ter sido comprometida, etc etc)

Não muda nada... excepto a segurança da CHAVE RSA, que passa a 4096 bits!

Não vejo qual seja o drama...

Em RESUMO: quem está a pedir um certificado através de um CSR criado SEMPRE com a mesma chave privada, pode muito bem gerar uma NOVA chave privada que tal não vai afectar o que quer que seja!!

Obrigado @marcolopes pelas boas prática. Ainda bem que não somos todos iguais, assim podemos todos aprender uns com os outros.
Sem drama: uma boa prática não é uma obrigação, mas é bom saber para decidirmos como actuar. Ou seja, é bom termos ideias claras porque fazemos as coisas.
A minha questão para o @desconfiado prendia-se com a versão da chave (HashControl) e sua utilização. 

[CPHJ1966]

Boas

Em relação às questões aqui levantadas, não me parece que também se tenha que alterar a chave quando se gera o HASH dos documentos. Eu vou continuar a usar a chave antiga. A At apenas menciona a obrigatoriedade dos 4096 bits para o certificado que vamos usar para comunicar via webservice. Espero que seja assim.

Obrigado

[CPHJ1966]

Em 08/04/2025 às 18:56, marcolopes disse:

"habitualmente quando pedimos um novo certificado não estamos a especificar uma nova chave privada. Fazemos um novo pedido CSR, mas a chave permanece a mesma."

Só se fores tu... Eu quando peço um NOVO certificado através de um CSR (Certificate Signing Request) crio SEMPRE UMA NOVA CHAVE PRIVADA RSA 2048 bits! (e porque não o haveria de fazer?? se é um NOVO certificado, eu posso decidir mudar a chave privada... até porque pode ter sido comprometida, etc etc)

Não muda nada... excepto a segurança da CHAVE RSA, que passa a 4096 bits!

Não vejo qual seja o drama...

Em RESUMO: quem está a pedir um certificado através de um CSR criado SEMPRE com a mesma chave privada, pode muito bem gerar uma NOVA chave privada que tal não vai afectar o que quer que seja!!

Boas

Uma vez que crias sempre uma nova chave privada quando pedes um novo certificado, a minha questão é: e passas a utilizar essa nova chave para criar o HASH dos documentos de faturação?

[123xyz]

Em 09/04/2025 às 12:48, CPHJ1966 disse:

Boas

Em relação às questões aqui levantadas, não me parece que também se tenha que alterar a chave quando se gera o HASH dos documentos. Eu vou continuar a usar a chave antiga. A At apenas menciona a obrigatoriedade dos 4096 bits para o certificado que vamos usar para comunicar via webservice. Espero que seja assim.

Obrigado

Até porque essa é de 1024 bits e não 2048 e o procedimento de alteração é completamente diferente. São chaves distintas. Eu uso a mesma desde 2013 (quando certifiquei). Uma coisa é assinar documentos outra é a comunicação de dados via WS (penso eu).

Edited April 9, 2025 at 04:24 PM by 123xyz

[Carrolo]

Em 09/04/2025 às 12:48, CPHJ1966 disse:

Boas

Em relação às questões aqui levantadas, não me parece que também se tenha que alterar a chave quando se gera o HASH dos documentos. Eu vou continuar a usar a chave antiga. A At apenas menciona a obrigatoriedade dos 4096 bits para o certificado que vamos usar para comunicar via webservice. Espero que seja assim.

Obrigado

Também acho que não.

É apenas o csr de comunicação com os web services da AT (aquele que tem validade de 2 anos, salvo erro) e que serve para pedir os códigos das guias de transporte, o registo das série (pedido ATCUD), etc.

[CPHJ1966]

Boas

Continuo com algumas dúvidas em relação ao HASH dos documentos. Se tivermos que usar a chave de 4096, vai ter que se mexer na programação.

Obg

Edited April 9, 2025 at 05:11 PM by CPHJ1966

[mganilho]

Em 08/04/2025 às 18:07, mganilho disse:

@desconfiado ao contrário do que alguns disseram, a tua questão parece-me pertinente (obrigado por nos fazeres pensar). Contudo, há um pequeno pormenor que resolve o problema e que creio que não estás a considerar.
O que estás a ver bem:

• habitualmente quando pedimos um novo certificado não estamos a especificar uma nova chave privada. Fazemos um novo pedido CSR, mas a chave permanece a mesma. Geralmente, apenas existe razão para alterar a chave privada, se esta for comprometida e existir receio que seja conhecida de terceiros. Ou seja, mudar de certificado não é realmente o mesmo que mudar de chave privada.
• agora foi solicitado que se utilize uma chave privada com uma nova dimensão, o que obrigatoriamente conduz a uma nova chave privada e a uma respectiva chave pública,, caso atípico para o que costumamos fazer.
• quando assinamos utilizamos o HASH do documento anterior da série

O que creio que estás a esquecer:

• quando submetemos um pedido de certificado, especificamos também à AT qual a versão da chave (número inteiro sequencial)
• quando assinamos um documento preenchemos a Hash e também colocamos essa versão no HashControl da chave que utilizámos 
• quando iniciamos e comunicamos uma série, não a associamos a nenhuma versão de chave privada.

Assim, parece-me que ao mudar a versão de uma chave podemos continuar a assinar documentos dentro de uma série que já possui documentos assinados com uma chave de versão anterior. No SAFT, para além do Hash, também é comunicado o HashControl. Por isso, a AT tem forma de saber a versão da chave privada que foi utilizada para assinar cada documento, podendo por isso utilizar o par respectivo da chave pública que nós lhe comunicámos.
 

Parece-me que estarei a relacionar os conceitos de forma correcta. Se alguém discordar, tinha muito interesse em o ouvir.
 

Realmente estava a fazer uma confusão a responder ao @desconfiado e a unificar o assunto de assinatura de documentos (Hash e HashControl) e comunicação por webservices AT.
Ou seja, por norma eu utilizo a mesma chave privada para assinar e para solicitar o certificado, mas realmente nada diz que assim tem de ser (obrigado @CPHJ1966 @123xyz @Carrolo e @Sergio.).
Estava convencido que indicávamos também a versão da chave ao submeter o CSR para obter certificado, mas afinal essa versão apenas é indicada no preenchimento do Modelo 24 na submissão do processo de certificação (juntamente com a submissão da chave pública respectiva). Assim, se por alguma razão se alterar a chave privada da produção da HASH será necessário respeitar este ponto do Despacho n.º 8632/2014:

Citação

2.1.4 - A mudança do par de chaves utilizado pelo programa certificado só pode ser realizada pela empresa produtora após comunicação à AT através de uma declaração modelo 24 e do upload da respetiva chave pública.

Desculpem a confusão.

Edited April 9, 2025 at 05:37 PM by mganilho

[sergiosmvc]

Em 09/04/2025 às 17:45, CPHJ1966 disse:

Boas

Continuo com algumas dúvidas em relação ao HASH dos documentos. Se tivermos que usar a chave de 4096, vai ter que se mexer na programação.

Obg

Já renovei sei lá umas 6 ou 7 vezes o certificado que uso para a comunicação das guias e das séries e nunca mexi na chave que gera o hash nos documentos...

[marcolopes]

On 4/9/2025 at 10:27 AM, mganilho said:

Obrigado @marcolopes pelas boas prática. Ainda bem que não somos todos iguais, assim podemos todos aprender uns com os outros.
Sem drama: uma boa prática não é uma obrigação, mas é bom saber para decidirmos como actuar. Ou seja, é bom termos ideias claras porque fazemos as coisas.
A minha questão para o @desconfiado prendia-se com a versão da chave (HashControl) e sua utilização. 

Ui que grande confusão que aqui vai!!!!!

Não fazia ideia que estavam a CONFUNDIR o certificado de comunicação WEBSERVICES com as CHAVES RSA relativas à CERTIFICAÇÃO utilizadas na assinatura de documentos!

Cum catano... NADA a ver!

A assinatura de documentos é efectuada com a CHAVE RSA PRIVADA, emitida após a certificação, que é do conhecimento APENAS do produtor (por exemplo, eu tenho uma segunda versão das CHAVES, pois tive de pedir uma "segunda via" devido a um LEAK pois a chave PRIVADA foi inadvertidamente enviada à própria AT por email!!! A AT revogou imediatamente a primeira versão, tendo emitido uma nova. Aí sim... entra em acção o campo "hashcontrol" que é a forma que a AT tem de IDENTIFICAR a CHAVE utlizada na assinatura dos documentos, que pode ter sido REEMITIDA ao longo do tempo!!!)

Agora está explicado o "drama" que estavam a criar! 😉

Edited April 9, 2025 at 07:25 PM by marcolopes

[marcolopes]

On 4/9/2025 at 5:45 PM, CPHJ1966 said:

Boas

Continuo com algumas dúvidas em relação ao HASH dos documentos. Se tivermos que usar a chave de 4096, vai ter que se mexer na programação.

Obg

NADA a ver!

Estamos no típico de WEBSERVICES...

Estamos a discutir a renovação do certificado de COMUNICAÇÃO com os WEBSERVICES da AT!

Não estamos a falar de questões LEGAIS (CERTIFICAÇÃO -> CHAVES RSA para assinatura de documentos!)

Edited April 9, 2025 at 07:24 PM by marcolopes

[paulofvoliveira]

Bom dia,

Já alguém recebeu a renovação pedida por email?

Em breve vamos ter que renovar o certificado e queria saber se o pedido pelo portal irá estar operacional ou não.

[1000s]

Eu recebi a dizer para usar o portal que o problema está resolvido.

Testei e está exatamente igual.

[123xyz]

Recebemos um novo email da AT a indicar que os problemas ocorridos na submissão do novo pedido/CSR via e-fatura estavam ultrapassados,

no entanto, ao submeter um novo CSR com chave RSA de 4096 bits, aparece agora o seguinte erro:

"A chave pública enviada no CSR tem que ser uma chave RSA de 2048 bits: no CSR indicou RSA de 4096 bits."

Não percebo qual é a lógica por detrás disto...

Edited April 10, 2025 at 10:16 AM by 123xyz

[CPHJ1966]

Em 10/04/2025 às 11:13, 123xyz disse:

Recebemos um novo email da AT a indicar que os problemas ocorridos na submissão do novo pedido/CSR via e-fatura estavam ultrapassados,

no entanto, ao submeter um novo CSR com chave RSA de 4096 bits, aparece agora o seguinte erro:

"A chave pública enviada no CSR tem que ser uma chave RSA de 2048 bits: no CSR indicou RSA de 4096 bits."

Não percebo qual é a lógica por detrás disto...

Eu também tentei agora e está igual. Vou ter que enviar à AT uma fatura das horas que perco por ano por questões como esta.

Já não tenho palavras para classificar a forma como o estado trabalha. É assim que ajudam as empresas?