Certificato di autenticazione del client non in scadenza, ma certificato "padre" IS

Ci dispiace, ma la risposta è "no". Il certificato radice di livello superiore "firma" gli altri certificati. Quando il tuo cliente va a convalidare il loro certificato, guarderà la firma su di esso e vedrà che è stato firmato da "oldcert", tenterà quindi di convalidare "oldcert" e scoprirà che "oldcert" ha scaduto. Il solo fatto di avere il nuovo certificato non significa nulla.

È possibile utilizzare le stesse "richieste di firma del certificato" originariamente utilizzate per ottenere i certificati firmati con il vecchio certificato e inviarli al nuovo server dei certificati e richiedere nuove firme. (Ci sono alcuni rischi, potresti duplicare un ID o qualcosa del genere). Ma poi devi ancora distribuire i nuovi certificati.

Lezione da portare via: quando firmi un certificato, assicurati che scada prima che il certificato di root scada.

Tu puoi "rigenerare" il certificato sul tuo gateway, ma funzionerà solo se avrai cura di riutilizzare lo stesso nome e la stessa chiave.

Questa è una catena di certificati: il certificato sul gateway è il "certificato CA" ei certificati client sono stati emessi da tale CA. Tale certificato cliente sarà ritenuto valido (ovvero "accettabile") se chiunque effettuerà la verifica potrà costruire una catena valida . Le condizioni sono elencate qui (non leggerlo, distruggerà la tua sanità mentale); principalmente si riducono a:

• Il subjectDN dell'emittente deve corrispondere al issuerDN del certificato emesso.
• La data corrente deve essere compresa tra la notBefore e la notAfter di ciascun certificato.
• La firma sul certificato emesso deve essere verificata con successo per quanto riguarda la chiave pubblica nel certificato emittente.

La conseguenza è che se produci un nuovo certificato CA (per il tuo "gateway") con un intervallo di validità più lungo, e fai attenzione ad usare lo stesso identico nome e la stessa identica chiave pubblica, allora il nuovo certificato funzionerà in sostituzione di quello precedente.

Un'ulteriore complicazione è che chiunque dovrà convalidare il certificato del cliente dovrà accedere al nuovo certificato CA anziché a quello vecchio. Probabilmente, il client può inviarlo come parte del protocollo (questo accade in alcuni protocolli, ad esempio SSL: quando il client invia il suo certificato, in realtà invia una catena completa), ma ciò richiederà ai sistemi client di conoscerlo. Qualsiasi certificato può contenere un link (URL) in un luogo dal quale il certificato della CA di emissione può essere scaricato (si chiama Accesso alle informazioni dell'autorità ); se questo è il caso, allora vorrai mettere il tuo nuovo certificato CA nel posto esatto, sostituendo quello vecchio.

Riepilogo: il tuo "Piano B" può funzionare, ma solo se riutilizzi lo stesso nome e la stessa chiave nel nuovo certificato, e potrebbe dipendere dall'uso esatto scenario. Il tuo software CA potrebbe essere problematico se insiste nel generare una nuova coppia di chiavi.

Nota: alcuni CA evitano questa situazione applicando il nidificazione delle date di validità: se un certificato CA termina il 13 dicembre 2014, si rifiuterà di emettere certificati con una data notAfter oltre dicembre 13th, 2014. La CA di Microsoft (Active Directory Certificate Services) è di questo tipo. Suppongo che il tuo software CA non applichi questa regola.