Salve @damikael ,
potresti confermare che per i Service Provider (es.Gestori full di servizi pubblici), ai fini dell’invio delle richieste di aggiornamento del metadata la scadenza che fa fede è quella del certificato di sigillo ed emesso da AgID?
Da quello che mi è noto, all’avvicinarsi della scadenza si deve ripercorrere l’iter per l’emissione di un nuovo certificato di sigillo e richiedere la validazione del metadata aggiornato.
Grazie
Maher AK
Buongiorno @MaherAK ,
alla scadenza del certificato di firma delle Request, contenuto nel metadata, sia nel caso in cui sia emesso da AgID sia nel caso di self signed (nel caso di SP pubblici non aggregatori), occorre richiedere aggiornamento del metadata ad AgID, secondo la procedura, inviando il nuovo metadata contenente il nuovo certificato.
Come best practice è sempre consigliato, al fine di evitare disservizi, richiedere l’aggiornamento prima della scadenza del certificato mantenendo nel metadata sia il vecchio che il nuovo.
Pertanto se il certificato in scadenza era stato emesso da AgID occorre prima fare richiesta di un nuovo certificato, modificare il metadata, rifirmarlo, quindi richiederne il collaudo.
Buongiorno, il certificato ricevuto da AGID come aggregatore se provo a generare il pfx per usare il certificato su IIS, mi da l’errore “No certificate matches private key” usando ovviamente la chiave privata generata con il CSR. Cosa stiamo sbagliando?
Buongiorno @damikael , riprendo questo post per chiarire il tuo suggerimento. Lavoro per un ente pubblico e il certificato self-signed scadrà a breve. Da quello che consigliavi tu nel tuo ultimo post, bisognerebbe:
La nostra implementazione è basata sul tuo repository spid-cie-php, che integra il componente SimpleSAML php. Nella documentazione di SimpleSAML ho trovato questa pagina che sembra descrivere lo scenario da te indicato: https://simplesamlphp.org/docs/stable/saml/keyrollover.html cioè il key rollover, che consiste nel creare un metadata con entrambe le chiavi, ma firmato con ancora la chiave vecchia. Poi la documentazione prevede un ultimo passaggio cioè un secondo aggiornamento del metadata con solo la chiave ‘nuova’.
Ora secondo me questo non è praticabile, perchè chiaramente non possiamo fare il submit ad Agid due volte del metadata, a stretto giro. Inoltre non mi convince il submit ad Agid del metadata generato dalla fase intermedia del key rollover con entrambe le chiavi, ma firmato ancora con la chiave vecchia, perchè nel nostro caso, a scadenza certificato, salterebbe tutto.
Io ho pensato a questo scenario:
Ho ragionato correttamente secondo te?
Grazie
Mauro
La firma del metadata serve solo a garantire l’integrità del documento, e non la validità (cosa invece necessaria per le interazioni SP/IdP e garantita quindi dai certificati presenti nel metadata).
Quindi puoi benissimo firmare il metadata con il certificato in scadenza.
@AGS ti ringrazio per la risposta. Tuttavia, oggi è arrivato avviso di aggiornare metadata di Aruba (l’identity provider) e ho notato che nel loro nuovo metadata hanno due chiavi, una in scadenza a breve e una nel 2027, ma la firma del metadata è con il certificato nuovo. Forse c’è differenza fra la prassi da seguire come service provider e quella per IDP?
Ripeto. la firma apposta sul metadata serve solo a verificare l’integrità del documento (ovvero che non sia stato alterato).
Allo scopo della firma quindi si può usare un qualunque certificato (ovviamente che soddisfi i requisiti tecnici previsti): quello vecchio, quello nuovo, o addirittura un terzo.
Aruba ha scelto di usare quello nuovo, ma non esiste un vincolo in tal senso.
Discorso diverso per la firma della AuthnRequest, delle Assertion e delle Response.
@AGS ti ringrazio per le spiegazioni, ora è più chiaro, penso che procederemo così allora.