9. Operazioni di Gestione dei Certificati X.509¶

Questa sezione definisce le procedure operative per la gestione dei Certificati X.509 all'interno della federazione IT-Wallet, coprendo l'analisi delle catene di Certificati X.509, le procedure di validazione e la verifica di revoca. Queste procedure completano i processi di onboarding della federazione e supportano la gestione continua del ciclo di vita dei Certificati X.509 per tutti i partecipanti.

Per l'infrastruttura PKI X.509 fondamentale e le procedure di emissione dei certificati, vedere trust-infrastructure:PKI X.509.

9.1. Architettura PKI della Federazione¶

La federazione IT-Wallet opera con un'infrastruttura a chiave pubblica gerarchica dove:

Trust Anchor: Agisce come Autorità di Certificazione X.509 Root dove i Certificati X.509 CA NON DEVONO superare il periodo di validità di 5 anni.

Certificato X.509 dell'Entità Federata: Ogni partecipante della federazione riceve un certificato X.509 che opera come sub-CA limitata dove i Certificati X.509 NON DEVONO superare il periodo di validità di 2 anni.

Certificati X.509 del Protocollo: Certificati X.509 auto-emessi per servizi interni dove i Certificati X.509 NON DOVREBBERO superare il periodo di validità di 1 anno.

Ogni entità federata DEVE esporre il proprio Certificato X.509 dell'Entità Federata su un endpoint pubblicamente accessibile. La chiave privata dell'Entità Federata serve a scopi duali:

Auto-emissione di Certificati X.509 del Protocollo per operazioni crittografiche interne (capacità sub-CA limitata).

Agire come Chiave dell'Entità Federata per la firma delle Dichiarazioni dell'Entità.

Nota

Le Foglie della Federazione possono SOLO emettere Certificati X.509 su se stesse e per scopi specifici dell'applicazione. Le Foglie della Federazione NON DEVONO emettere Certificati X.509 per altre entità federate, come limitato dalle loro Autorità Federali utilizzando l'estensione X.509 Name Constraints.

Per i Certificati X.509 specifici del protocollo, con periodi di validità superiori a 24 ore, l'entità emittente DEVE pubblicare e aggiornare regolarmente una Lista di Revoca dei Certificati X.509 (CRL) su un endpoint pubblicamente accessibile.

9.2. Struttura e Analisi della Catena di Certificati X.509¶

Le entità federate ricevono catene di Certificati X.509 durante il processo di onboarding. Le entità federate DEVONO validare queste catene su se stesse.

9.2.1. Visualizzazione della Catena di Certificati X.509¶

Il seguente script consente alle entità federate di:

Estrarre i dettagli dei certificati X.509 per la verifica.

Analizzare le estensioni e i vincoli dei certificati X.509.

Verificare la gerarchia e le relazioni dei certificati X.509

Listato 9.1 Script di analisi della catena di Certificati X.509¶

#!/bin/bash
# Certificate chain analysis for federation entities
# Array containing certificates in DER format encoded in Base64
certificate_chain=(
    "MIIDyzCCA3GgAwIBAgI..." # Federation Entity Certificate
    "MIIDQzCCAuigAwIBAgI..." # Trust Anchor Certificate
)

# Display first certificate (Federation Entity)
echo "===================================="
echo " Federation Entity Certificate Analysis"
echo "===================================="
echo
echo "${certificate_chain[0]}" | base64 -d > federation_entity.der
openssl x509 -in federation_entity.der -inform DER -text -noout

# Display second certificate (Trust Anchor)
echo "====================================="
echo " Trust Anchor Certificate Analysis"
echo "====================================="
echo
echo "${certificate_chain[1]}" | base64 -d > trust_anchor.der
openssl x509 -in trust_anchor.der -inform DER -text -noout

# Cleanup temporary files
rm federation_entity.der trust_anchor.der

9.2.2. Validazione della Catena di Certificati X.509¶

Le entità federate DEVONO validare le catene di certificati X.509 per garantire l'instaurazione corretta della fiducia e verificare la conformità con i requisiti PKI della federazione.

Un esempio non normativo della procedura di validazione della catena di Certificati X.509 è fornito di seguito:

Listato 9.2 Script di validazione della catena di Certificati X.509¶

#!/bin/bash
# Certificate chain validation for federation entities

# Convert DER certificates to PEM format for validation
openssl x509 -inform der -in federation_entity.der -out federation_entity.pem
openssl x509 -inform der -in trust_anchor.der -out trust_anchor.pem

# Validate Trust Anchor certificate (self-signed)
echo "Validating Trust Anchor certificate..."
openssl verify -CAfile trust_anchor.pem trust_anchor.pem

# Validate Federation Entity certificate against Trust Anchor
echo "Validating Federation Entity certificate..."
openssl verify -CAfile trust_anchor.pem federation_entity.pem

# Cleanup
rm federation_entity.pem trust_anchor.pem

Le entità federate DOVREBBERO verificare:

Firme dei Certificati X.509: Ogni Certificato X.509 DEVE essere correttamente firmato dal suo emittente.

Integrità della Catena di Certificati X.509: Le relazioni Emittente-Soggetto DEVONO essere valide in tutta la catena di Certificati X.509.

Periodi di Validità dei Certificati X.509: Tutti i Certificati X.509 DEVONO essere entro i loro periodi di validità e DEVONO conformarsi ai limiti della federazione.

Estensioni dei Certificati X.509: I Vincoli di Base e l'Uso della Chiave DEVONO conformarsi ai requisiti della federazione:

Certificati X.509 dell'Entità Federata: CA:TRUE, pathlen:0 (può solo emettere certificati su se stessa).

Certificati X.509 del Protocollo: CA:FALSE (non può emettere certificati).

9.3. Gestione della Revoca dei Certificati X.509¶

Le entità federate DEVONO implementare la verifica di revoca dei Certificati X.509 per garantire la validazione continua della fiducia e la conformità con i requisiti di sicurezza della federazione.

9.3.1. Distribuzione e Accesso CRL¶

Le autorità federali pubblicano Liste di Revoca dei Certificati X.509 (CRL) su endpoint pubblicamente accessibili. Le entità federate DEVONO essere in grado di accedere e processare queste distribuzioni CRL per la verifica di revoca.

La seguente procedura consente alle entità federate di:

Localizzare gli endpoint di distribuzione CRL dai Certificati X.509.

Scaricare le liste di revoca correnti.

Analizzare il contenuto CRL e i periodi di validità.

9.3.2. Verifica della Revoca dei Certificati X.509¶

Le entità federate DEVONO verificare lo stato di revoca dei certificati X.509 controllando i numeri seriali dei certificati X.509 contro le Liste di Revoca dei Certificati X.509 correnti.

Le entità federate DOVREBBERO implementare controlli di revoca automatizzati per:

Certificati X.509 dell'Entità Federata: Verificare periodicamente lo stato del proprio certificato X.509.

Certificati X.509 delle Entità Peer: Validare i Certificati X.509 di altri partecipanti della federazione.

Validazione della Catena di Fiducia: Garantire che intere catene di certificati X.509 rimangano valide.

Di seguito è fornito un esempio non normativo di script bash per la verifica dello stato di revoca dei certificati X.509:

9.4. Migliori Pratiche per la Gestione dei Certificati X.509¶

9.4.1. Integrazione della Validazione dei Certificati X.509¶

Le entità federate DOVREBBERO integrare le procedure di validazione dei Certificati X.509 nelle loro operazioni standard della federazione:

Aggiornamenti della Configurazione dell'Entità: Verificare le catene di Certificati X.509 quando si processano gli authority hints e gli aggiornamenti dei Certificati X.509.

Costruzione della Catena di Fiducia: Validare tutti i Certificati X.509 durante le procedure di costruzione della catena di fiducia.

Operazioni PKI X.509: Eseguire controlli di revoca dei Certificati X.509 utilizzando gli endpoint CRL.

Gestione dei Certificati del Protocollo: Validare il Certificato X.509 specifico del protocollo auto-emesso per i servizi interni.

Validazione Periodica: Implementare programmi regolari di validazione dei Certificati X.509 e CRL.

9.4.2. Diagnostica e Risoluzione dei Problemi¶

Le entità federate DEVONO implementare procedure diagnostiche per identificare e risolvere problemi relativi ai Certificati X.509:

Validazione dei Certificati X.509, inclusi:

Discrepanze dell'Identificatore della Chiave dell'Autorità: L'Identificatore della Chiave dell'Autorità CRL non corrisponde all'Identificatore della Chiave del Soggetto del Trust Anchor.

Rotazione del Certificato X.509 del Trust Anchor: Certificato X.509 del Trust Anchor obsoleto che causa fallimenti di validazione.

Problemi del Formato del Numero Seriale: Problemi di normalizzazione del numero seriale nel controllo di revoca.

Fallimento della Validazione CRL: Quando la validazione CRL fallisce, le entità federate DOVREBBERO:

Verificare il Certificato X.509 del Trust Anchor: Garantire che venga utilizzato il certificato X.509 del Trust Anchor corrente.

Controllare l'Identificatore della Chiave dell'Autorità: Confrontare l'Identificatore della Chiave dell'Autorità CRL con l'Identificatore della Chiave del Soggetto del Trust Anchor.

Validare la Firma CRL: Verificare che la CRL sia correttamente firmata dall'autorità emittente prevista.

Aggiornare il Certificato X.509 del Trust Anchor: Scaricare il certificato X.509 del Trust Anchor aggiornato se è avvenuta una rotazione.

Verifica dell'Accessibilità degli Endpoint: Le entità federate DOVREBBERO implementare test di connettività per gli endpoint dell'infrastruttura dei certificati.

Il seguente esempio non normativo fornisce uno script per il test di connettività dell'infrastruttura dei certificati X.509 della Federazione:

9.4.3. Coordinamento del Ciclo di Vita dei Certificati X.509¶

Le entità federate DEVONO coordinare la gestione dei Certificati X.509 con le procedure del ciclo di vita della federazione seguendo i periodi di validità stabiliti:

Rinnovo dei Certificati X.509: Allineare i rinnovi dei certificati X.509 con gli aggiornamenti della Configurazione dell'Entità e i cicli di aggiornamento dei Trust Mark, secondo i limiti della federazione definiti in Architettura PKI della Federazione.
Rotazione delle Chiavi: Coordinare la rotazione della Chiave dell'Entità Federata con le procedure di rinnovo dei certificati X.509.
Gestione CRL: Per i Certificati X.509 del Protocollo con validità > 24 ore, mantenere la pubblicazione CRL corrente.
Uscita dalla Federazione: Garantire la revoca corretta dei Certificati X.509 durante l'uscita volontaria o avviata dall'organo di supervisione dalla federazione.

9.4.3.1. Gestione del Ciclo di Vita dell'Entità¶

Questa sezione fornisce le procedure di implementazione tecnica per la gestione del ciclo di vita dell'entità. Per i concetti di alto livello del ciclo di vita e i processi aziendali, vedere onboarding-high-level:Gestione del Ciclo di Vita dell'Entità.

Mentre l'aggiornamento dei dati amministrativi DEVE seguire processi di governance che sono fuori dall'ambito di questa specifica tecnica, gli aggiornamenti della configurazione tecnica sono descritti nelle seguenti sezioni.

9.5. Aggiornamenti della Configurazione Tecnica¶

Gli aggiornamenti tecnici che influenzano le operazioni del protocollo della federazione DEVONO seguire procedure specifiche per:

Rinnovo dei Certificati X.509

Preparazione Pre-rinnovo: L'Entità DEVE generare un nuovo CSR con informazioni aggiornate del certificato X.509.

Richiesta di Rinnovo: L'Entità DEVE inviare la richiesta di rinnovo con il nuovo CSR seguendo la stessa procedura tecnica dell'onboarding iniziale.

Integrazione del Certificato X.509: L'Entità DEVE aggiornare la sua Configurazione dell'Entità con la nuova catena di certificati X.509 nel parametro x5c.

Validazione della Catena di Fiducia: L'Entità DEVE verificare la Catena di Fiducia aggiornata attraverso l'endpoint /resolve.

Aggiornamento del Registro: L'Entità DOVREBBE confermare le informazioni dell'entità aggiornate nell'endpoint /list del Trust Anchor.

Rotazione delle Chiavi

Attivazione della Chiave: In caso di incidente o rotazione pianificata, l'Entità DEVE attivare una Chiave dell'Entità di Federazione alternativa per le operazioni di firma.

Generazione di Nuova Chiave: L'Entità DEVE generare una nuova coppia di Chiave Pubblica dell'Entità di Federazione per servire come chiave aggiuntiva.

Pubblicazione Parallela delle Chiavi: L'Entità DEVE pubblicare tutte le chiavi disponibili nella claim jwks della Configurazione dell'Entità durante il periodo di transizione.

Richiesta di Certificato X.509: L'Entità DEVE richiedere un nuovo certificato X.509 per la nuova chiave seguendo la procedura standard.

Migrazione Graduale: L'Entità DEVE aggiornare la Configurazione dell'Entità per utilizzare la chiave attivata per la firma mantenendo tutte le chiavi per la verifica.

Deprecazione della Chiave Vecchia: L'Entità DEVE rimuovere la vecchia chiave dalla Configurazione dell'Entità dopo il periodo di validazione, mantenendo la chiave alternativa e la nuova chiave.

Aggiornamenti dei Metadati

Modifiche degli Endpoint: L'Entità PUÒ aggiornare gli endpoint di servizio nei metadati specifici dell'entità.

Aggiornamenti delle Capacità: L'Entità PUÒ modificare i protocolli supportati, gli algoritmi o le capacità di servizio entro i vincoli definiti da questo profilo di implementazione IT-Wallet.

Tutti gli aggiornamenti tecnici DEVONO essere validati attraverso:

Validazione della Configurazione dell'Entità: L'Entità DEVE verificare la struttura e il contenuto della EC aggiornata.

Risoluzione della Catena di Fiducia: L'Entità DEVE confermare che l'endpoint /resolve restituisca una Catena di Fiducia valida.

Stato della Federazione: L'Entità DEVE verificare lo stato operativo dell'entità nel registro della federazione.

Test di Integrazione: L'Entità DOVREBBE testare le operazioni del protocollo della federazione con la configurazione aggiornata.

9.6. Procedure Tecniche di Uscita dalla Federazione¶

Per il contesto aziendale sui processi di uscita dalla federazione, vedere Processi di Uscita e Rimozione dalla Federazione. Questa sezione copre le procedure di implementazione tecnica.

9.6.1. Uscita Volontaria - Disattivazione Tecnica¶

Richiesta di Revoca del Certificato X.509: L'Entità DEVE inviare una richiesta di revoca del Certificato X.509 all'Autorità Federata con il motivo della revoca. La richiesta DEVE essere firmata con la Chiave Privata dell'Entità Federata corrispondente al Certificato X.509 che viene revocato per dimostrare la legittimità della richiesta di revoca.

Verifica dell'Aggiornamento CRL: L'Autorità Federata DEVE revocare il Certificato X.509 dell'Entità e l'Entità DEVE verificare che appaiano nella Lista di Revoca dei Certificati X.509 aggiornata.

Rimozione della Dichiarazione Subordinata: L'Autorità Federata DEVE rimuovere completamente la Dichiarazione Subordinata dell'Entità dal Registro della Federazione per prevenire qualsiasi validazione del rapporto di fiducia, e quindi rimuovere qualsiasi riferimento a quella Entità nell'endpoint di elenco, endpoint di risoluzione o endpoint di elenco con trust mark.

Disattivazione della Configurazione dell'Entità: L'Entità DEVE disattivare la sua Configurazione dell'Entità. L'Entità PUÒ:

Rimuovere completamente la Configurazione dell'Entità dall'endpoint /.well-known/openid-federation (restituendo HTTP 404), OPPURE

Mantenere la Configurazione dell'Entità come scaduta (con la claim exp nel passato). Pertanto NON DEVE aggiornarla con timestamp freschi.

Aggiornamento dello Stato del Registro: L'Entità DOVREBBE verificare la rimozione dal Registro della Federazione, verificando anche lo stato del Trust Mark utilizzando l'endpoint dello Stato del Trust Mark.

Esempio non normativo di richiesta di revoca del Certificato X.509 seguendo il formato RFC 3280:

Richiesta di Revoca del Certificato X.509:
Soggetto: CN=credentials.example.gov, OU=Digital Credentials, O=Example Organization, L=Roma, ST=Lazio, C=IT, emailAddress=technical@credentials.example.gov
Numero Seriale del Certificato X.509: 987654321
Motivo della Revoca: cessation_of_operation (5)
Data di Revoca: 2025-12-31T23:59:59Z

Richiesta firmata con la Chiave Privata dell'Entità Federata corrispondente a:
Algoritmo della Chiave Pubblica: id-ecPublicKey
OID ASN1: prime256v1
CURVA NIST: P-256
ID Chiave: NsXymfIILEPR5Y0t

Nota: La CRR DEVE essere firmata con la stessa chiave privata che corrisponde al
certificato X.509 che viene revocato per autenticare la richiesta di revoca.

Esempio CRR in formato DER (codificato Base64):

9.6.2. Rimozione da Parte dell'Organo di Supervisione - Implementazione Tecnica¶

Revoca di Emergenza del Certificato X.509: L'Autorità Federata DEVE revocare immediatamente il Certificato X.509 con il codice di motivo appropriato (ad es., "Key Compromise", "Cessation of Operation").

Aggiornamento di Emergenza CRL: Il Trust Anchor DEVE pubblicare la CRL aggiornata entro il tempo di emergenza.

Rimozione della Dichiarazione Subordinata: L'Autorità Federata DEVE interrompere immediatamente l'emissione delle Dichiarazioni Subordinate dell'Entità utilizzando l'endpoint fetch, e/o qualsiasi riferimento a quella Entità utilizzando l'endpoint di elenco, o l'endpoint di elenco con trust mark, o l'endpoint di risoluzione.

Invalidazione della Configurazione dell'Entità: La Configurazione dell'Entità in /.well-known/openid-federation diventa invalida a causa della revoca del Certificato X.509 (la verifica della firma fallisce).

Invalidazione della Catena di Fiducia: La risoluzione della Catena di Fiducia DEVE restituire uno stato di errore per l'entità interessata.

Isolamento degli Endpoint di Servizio: L'infrastruttura della federazione DEVE bloccare l'accesso agli endpoint di servizio della federazione.

Esempio di verifica di revoca di emergenza:

# Controlla l'aggiornamento di emergenza CRL
curl -o emergency.crl https://trust-anchor.eid-wallet.example.it/pki/ta-sub.crl
openssl crl -in emergency.crl -text -noout | grep "Last Update"

# Verifica che la risoluzione della Catena di Fiducia fallisca
curl "https://trust-anchor.eid-wallet.example.it/resolve?sub=https%3A//suspended-entity.example.it&trust_anchor=https%3A//trust-registry.eid-wallet.example.it"
# Previsto: HTTP 404 o risposta di errore specifica

Modifiche Tecniche a Livello di Componente

Componenti tecnici specifici POSSONO essere modificati mantenendo l'appartenenza alla federazione:

{
  "iss": "https://ci.example.it",
  "sub": "https://ci.example.it",
  "jwks": {
    // contenuto jwks
  },
  "metadata": {
    "openid_credential_issuer": {
      "credential_endpoint": "https://ci.example.it/credential",
      "credentials_supported": [ ]
      // rimosso: "batch_credential_endpoint" per manutenzione
    }
  }
}

L'Entità DEVE seguire questi passaggi per le modifiche dei componenti:

Aggiornamento della Configurazione dell'Entità: L'Entità DEVE modificare i metadati per riflettere le modifiche dei componenti.
Rivalidazione della Catena di Fiducia: L'Entità DEVE verificare la configurazione aggiornata attraverso l'endpoint /resolve.
Test del Servizio: L'Entità DOVREBBE testare le operazioni del protocollo della federazione rimanenti.
Verifica del Registro: L'Entità DOVREBBE confermare le capacità aggiornate nel registro della federazione.

Obblighi Tecnici Post-Uscita

Le entità che escono dalla federazione DEVONO mantenere quanto segue per la conformità normativa:

Configurazione Storica dell'Entità: L'Entità DEVE mantenere l'accessibilità dell'endpoint /.well-known/openid-federation per scopi di audit.
Archivio della Catena di Certificati X.509: L'Entità DEVE mantenere le catene di Certificati X.509 accessibili per la verifica delle Credenziali esistenti (minimo 7 anni).
Conservazione dei Log di Audit: L'Entità DEVE archiviare i log del protocollo della federazione per i requisiti normativi.