66 30/03/2026 07/04/2026 7 min

Risoluzione per l’errore EXPKEYSIG del repository MySQL su Debian Bookworm

L’errore EXPKEYSIG indica che APT ha trovato una firma associata a una chiave scaduta, revocata o non più valida per il repository MySQL. Su Debian Bookworm il caso più comune è un archivio MySQL configurato con una chiave GPG vecchia, oppure un file sorgente APT che punta a un repository corretto ma firmato con una chiave ormai non più accettata dal sistema.

Il principio giusto non è “forzare l’aggiornamento”, ma verificare prima la sorgente, poi la chiave, poi la firma. In questo modo eviti di mascherare un problema reale di trust e mantieni il sistema aggiornabile in modo pulito.

Diagnosi probabile

La causa più probabile è una di queste:

  • chiave GPG del repository MySQL scaduta o sostituita;
  • repository configurato con URL o distribuzione non coerente con Debian Bookworm;
  • vecchio keyring ancora referenziato in /etc/apt/sources.list.d/;
  • cache APT o metadati non aggiornati dopo il cambio della chiave.

In pratica, APT rifiuta il repository perché non riesce a validare la firma con una chiave considerata attendibile. Il pacchetto non è necessariamente corrotto: il problema è quasi sempre nel livello di autenticazione del repository.

Verifiche immediate

Prima di cambiare qualcosa, controlla questi tre punti. Sono veloci e ti dicono subito dove sta il guasto.

  1. Leggi l’errore esatto di APT
    Il messaggio tipico contiene EXPKEYSIG e una fingerprint, per esempio una stringa simile a EXPKEYSIG B7B3B788A8D3785C. Quella fingerprint serve per capire quale chiave è coinvolta.
  2. Controlla il file sorgente del repository MySQL
    grep -RniE 'mysql|repo.mysql.com' /etc/apt/sources.list /etc/apt/sources.list.d/

    Esito atteso: trovi uno o più file che puntano a repo.mysql.com. Se il repository è scritto male o punta a una release sbagliata, il problema non è la chiave ma la sorgente.

  3. Verifica se esiste un keyring MySQL vecchio
    ls -l /etc/apt/trusted.gpg.d/ /usr/share/keyrings/ | grep -i mysql

    Esito atteso: individui eventuali file legati a MySQL. Se trovi una chiave vecchia nel posto sbagliato, APT può continuare a usarla o a ignorare quella nuova.

Se vuoi un controllo più preciso sulla firma, puoi anche aggiornare l’indice APT in modalità verbosa e leggere l’errore completo:

apt update

Esito atteso: compare la riga con EXPKEYSIG e il repository MySQL viene marcato come non verificabile.

Soluzione consigliata passo-passo

La soluzione più sicura è sostituire la chiave obsoleta con il keyring ufficiale, poi ricollegare il repository a quel keyring. Su Debian Bookworm questo approccio è preferibile rispetto all’uso di apt-key, che è deprecato e meno pulito dal punto di vista della sicurezza.

  1. Fai un backup dei file APT coinvolti
    Prima di modificare la configurazione, salva la sorgente e l’eventuale keyring locale:
    sudo cp -a /etc/apt/sources.list.d /root/backup-sources.list.d.$(date +%F_%H%M%S)

    Se esiste un file specifico per MySQL, è utile copiarlo anche singolarmente. Condizione di successo: hai una copia ripristinabile prima della modifica.

  2. Scarica la chiave aggiornata nel formato corretto
    Il metodo più ordinato è salvare la chiave in /usr/share/keyrings/ o in un percorso equivalente usato dal repository. Un flusso tipico è questo:
    curl -fsSL https://repo.mysql.com/RPM-GPG-KEY-mysql-2023 | gpg --dearmor | sudo tee /usr/share/keyrings/mysql.gpg > /dev/null

    Esito atteso: viene creato un file keyring leggibile da APT. Se l’URL della chiave cambia nel tempo, verifica sul sito ufficiale MySQL quale chiave corrente è pubblicata per il repository.

  3. Correggi la voce del repository MySQL
    Apri il file di repository, ad esempio /etc/apt/sources.list.d/mysql.list, e fai in modo che usi il keyring appena creato. Un esempio coerente è questo:
    deb [signed-by=/usr/share/keyrings/mysql.gpg] http://repo.mysql.com/apt/debian/ bookworm mysql-8.0

    Se stai usando MySQL 8.4 o un ramo diverso, la sezione finale può cambiare. L’importante è che la distribuzione sia bookworm e che il parametro signed-by punti alla chiave corretta.

  4. Elimina eventuali riferimenti alla vecchia chiave
    Se il sistema ha ancora una chiave MySQL importata con vecchi metodi, rimuovi il riferimento obsoleto solo dopo aver verificato che il nuovo keyring funzioni. Controlla i file sotto /etc/apt/trusted.gpg e /etc/apt/trusted.gpg.d/. Se trovi una chiave MySQL vecchia, non cancellarla alla cieca: prima conferma che il repository aggiorni correttamente con la nuova chiave.
  5. Ricarica i metadati APT
    sudo apt update

    Esito atteso: l’errore EXPKEYSIG non compare più e il repository MySQL viene letto senza warning di firma. Se vedi ancora l’errore, il problema è quasi sempre uno di questi due: il file sorgente punta a un keyring errato oppure la chiave scaricata non è quella attualmente pubblicata dal repository.

  6. Verifica il pacchetto o il componente interessato
    Se il repository serve per installare o aggiornare MySQL, prova a leggere i candidati disponibili senza fare ancora modifiche distruttive:
    apt-cache policy mysql-server

    Esito atteso: il repository MySQL compare tra le origini e APT mostra una versione candidata coerente con Bookworm.

Alternativa B: reinstallare il repository ufficiale MySQL

Se la configurazione è sporca, il modo più rapido e reversibile è reinstallare il pacchetto di configurazione repository fornito da MySQL, quando disponibile per Debian:

  1. Rimuovi o rinomina il file sorgente rotto in /etc/apt/sources.list.d/.
  2. Scarica e installa il pacchetto di configurazione del repository MySQL dalla fonte ufficiale.
  3. Riesegui apt update e controlla che la firma sia accettata.

Questa strada è utile quando sono presenti residui di configurazioni vecchie, copie manuali di chiavi o repository duplicati. È meno elegante del keyring curato a mano, ma spesso chiude il problema in modo più veloce.

Controlli finali / rollback

Dopo il fix, valida sempre questi punti:

  1. Controllo APT
    sudo apt update

    Condizione di successo: nessun errore EXPKEYSIG e nessun warning di firma per il repository MySQL.

  2. Controllo sorgente
    grep -Rni 'repo.mysql.com' /etc/apt/sources.list /etc/apt/sources.list.d/

    Condizione di successo: trovi una sola configurazione coerente, non duplicati e non riferimenti a chiavi vecchie.

  3. Controllo keyring
    ls -l /usr/share/keyrings/mysql.gpg

    Condizione di successo: il file esiste, è leggibile dal sistema e corrisponde al keyring usato nella riga deb.

  4. Rollback
    Se qualcosa non funziona, ripristina i file salvati nel backup di /etc/apt/sources.list.d, rimuovi il keyring aggiunto e riesegui apt update. Il rollback è sicuro finché non hai già disinstallato pacchetti o rimosso componenti del database.

Una regola pratica utile: se il repository MySQL è l’unico che fallisce, non toccare tutto APT. Lavora solo su quella sorgente, perché il problema quasi mai riguarda Debian Bookworm nel suo insieme, ma il trust del repository esterno.

Perché non usare più apt-key

Molti vecchi tutorial suggeriscono apt-key add. Su sistemi moderni è meglio evitarlo: centralizza le chiavi in modo poco controllabile e rende più difficile capire quale repository stia usando quale firma. Il meccanismo con signed-by è più pulito, più leggibile e più facile da debuggare in futuro.

In pratica, ogni repository importante dovrebbe avere la sua chiave dedicata. Così, se una chiave scade o viene sostituita, il problema resta confinato a quel solo archivio e non sporca il trust globale del sistema.

Quando l’errore non è la chiave

Se dopo aver sistemato il keyring l’errore persiste, considera queste verifiche:

  • la release è davvero bookworm e non bullseye o buster;
  • l’URL del repository è corretto e raggiungibile;
  • il server ha l’orario corretto, perché un clock sballato può falsare la validazione delle firme;
  • non ci sono proxy, mirror o filtri che alterano i metadati APT.

Per controllare l’ora del sistema, puoi usare:

timedatectl status

Esito atteso: data e ora corrette, sincronizzazione attiva. Un orologio fuori fase non genera sempre EXPKEYSIG, ma può complicare la diagnosi e produrre errori di validazione simili.

Checklist rapida

  1. Ho identificato il file sorgente MySQL in /etc/apt/sources.list.d/.
  2. Ho sostituito la chiave vecchia con un keyring ufficiale e separato.
  3. Ho usato signed-by nella riga del repository.
  4. Ho eseguito apt update senza errori di firma.
  5. Ho conservato un backup per un rollback immediato.

Se il repository è stato configurato da un installer, da un pannello o da uno script di provisioning, il controllo finale più importante è sempre lo stesso: una sola sorgente MySQL, una sola chiave, un solo risultato pulito in apt update.