Ciao a tutto sto avendo problemi con il server https://get.dgc.gov.it/v1/dgc/signercertificate/update.
Ha smesso di funzionare… Qualcuno ha informazioni al riguardo?
Speriamo sia solo una questione di “manutenzione” e non di “carichi” o di “attacchi” altrimenti si parte davvero male.
ciao! lo hanno segnalato anche in una issue del mio progetto, stasera controllo sembra che abbiano cambiato la logica della gestione del TOKEN, prova a vedere se quello che suggeriscono qui funziona:
Ma no, è un bad Gateway, qua mi da più l’idea che sia cascato tutto
Ok, dunque, io sto cercando di capire cosa sta succedendo.
Facendo un paio di test, in effetti se metto come start il headers[“x-resume-token”] = 0; Risponde,
il problema è che non cambia mai il x-resume-token che ritorna sempre 1, quindi continua a fare iinterrottamente la solita chiamata, ergo non si ferma mai.
Non è cascato tutto, ma sta succedendo qualcosa di strano.
In realtà io sto testando e con X-RESUME-TOKEN a 0 funziona, mi ritorna ricorsivamente 1,2,3,4… ma la chiamata con token 4 ritorna “Bad Gateway”.
Ora anche a me.
Ho fatto alcune prove a partire partendo da 5 e arrivo a 234 prima di un nuovo bad gateway.
Esatto, stavo verificando la stessa cosa.
Dal successivo si arriva a 293 che risponde
KID: oGix7vDtlq4=
TOKEN: 294
il 294 va in status “204 No content”.
Verificando su https://get.dgc.gov.it/v1/dgc/signercertificate/status sembra che l’ultimo KID sia quello.
Di conseguenza i problemi sono relativi ai resume-token: vuoto, 4 e 234.
Esatto, anche io ottengo questo, ho fatto un try catch con un aumento manuale del token e “tralasciando i bad gateway” e arrivo li anche io…
Ma sarà corretto?
Non penso sia corretto perché in realtà sono due KID che esistono in /status
:
KID: vvYa1vaWkGg=
KID: T8kbYovQlYU=
guardando nelle liste JSON sono due KID associati a NL e GR (SE DCC Trust Point - Main page , premendo su INSPECT TRUST LIST):
"GR" : {
"eku" : {
"vvYa1vaWkGg=" : [ "1.3.6.1.4.1.0.1847.2021.1.1", "1.3.6.1.4.1.0.1847.2021.1.2", "1.3.6.1.4.1.0.1847.2021.1.3" ]
...
...
"NL" : {
"eku" : {
...
"T8kbYovQlYU=" : [ "1.3.6.1.4.1.0.1847.2021.1.1" ],
...
},
Però è anche vero che potrebbero averli tolti(i certificati) per qualche ragione.
La ragione ad ora mi sfugge, però ad ora credo che più che ignorare i 502 non si possa fare.
Speriamo sistemino la cosa il prima possibile.
Confermo che ho provato a cancellare i dati e riscaricare Verifica C-19, la app è rotta. Il mio greenpass non viene validato.
Quindi non so se questa situazione è studiata, cioè se si presuppone che le persone abbiano scaricato i propri certificati la scorsa notte e quindi stanno operando ora, oppure è un bug grossino
Mentre scaricandomi gli update e gli status ignorando i bad gateway e facendo la validazione con la DCC-utils, il mio green pass risulta valido…
anche io ho fatto lo stesso test ed è uguale al tuo! è da un po di ore che non funziona.
Non so se è un Bug o una modifica voluta da loro senza avvertire nessuno, mi sembra strano perché è una cosa che non accade mai…
Si, io che non aprivo l’app VerificaC19 da un paio di settimane mi sono trovato già stamattina con questo problema.
Io non ho usato la libreria DCC-util, ma una per php (GitHub - herald-si/verificac19-sdk-php: PHP Digital Green Certificate SDK) che fa i controlli seguendo l’sdk android e ti confermo che per come lavora, se ignori i Bad Gateway, la validazione è sicuramente funzionante in quanto i certificati corrotti non sono tra quelli italiani. al massimo si hanno dei problemi per i greenpass greci ed olandesi.
In ogni caso, seguendo le regole dell’SDK, lo scarico va fatto ogni 24h dal link “rotto” e per questo motivo non dovrebbe essere possibile validare nulla (esattamente come per verificaC19)
La libreria l’avevo vista, ma ho preferito piuttosto, da backend, farla più sporca e lanciare la dcc-utils in node-js per essere più sicuro e magari nel caso metteessero com sdk utilizzabile quella, essere già compliant. Comunque, si, unica cosa è che se entro stanotte non sistemano la cosa domani tutte le app verifica c-19 italiane saranno rotte.
Ripartito, da un X-RESUME-TOKEN vuoto viene scaricata la lista completa
“Huston, abbiamo un problema” : possibile leak delle chiavi private per la firma dei Gp https://twitter.com/reversebrain/status/1453095038284615682?s=21
al limite di UNA chiave privata. da cui l’esistenza della CRL per le chiavi private.
Per ora l’evidenza è una chiave privata, di un ente di emissione francese, ma è legata ad un Green Pass pubblicato in un forum come prova della possibilità di emettere GP validi a 300€ l’uno, poi che sia la sola chiave soggetta a leak è da verificare. Di fatto questo però potrebbe dar luogo all’invalidazione di tutti i GP emessi con quella chiave, non solo quelli fatti con dolo. L’unico problema che vedo è il dover gestire la riemissione dei GP validi in un contesto dove non esiste in Europa un solo canale di distribuzione e dove molte persone ce l’hanno in versione cartacea.
Credo abbiano già razzato via tutto perché quello in discussione nel tweet a me lo da invalido ad ora.