Esiste un certificato SSL senza scadenza?

In effetti, sì, è possibile generare il proprio certificato di origine (ovvero diventare la propria Autorità di certificazione) e quindi firmare ogni CSR del certificato SSL con la chiave radice. Quindi sarai in grado di impostare la data di scadenza in modo futuro (ad esempio, utilizzare una stima del prodotto molto ottimistica) sul certificato SSL installato su ciascun dispositivo. L'unico neo è che il certificato di root dovrà essere installato come root attendibile in ogni Web client browser che accede alle funzioni di amministrazione. Se questo è troppo complicato per i tuoi utenti, potrebbero semplicemente considerare ogni certificato singolarmente che potrebbe essere più semplice. In realtà, avendo pensato un po 'di più su questo, ogni singolo certificato dovrebbe essere associato a un certo nome host o indirizzo IP comunque per evitare qualsiasi altro avviso del browser (ad esempio il nome host del certificato non corrisponde al nome host effettivo nel browser) quindi il nome host dovrebbe essere "hard coded" nel dispositivo. Poiché questo non è pratico, ogni utente dovrebbe fare clic su oltre l'avviso del browser per accedere al dispositivo. La soluzione è che dovrai fare in modo che possano aggiornare il certificato da solo per rimuovere completamente gli avvisi del browser o potresti fare in modo che il dispositivo generi il proprio certificato.

Il mio ZyXel NAS offre la funzionalità per generare il proprio e consente di impostare il nome comune per il certificato:

Lagenerazionedicertificatipersonalizzatiavràglistessivantaggidicrittografiadell'utilizzodelleautoritàdicertificazionepubblichee,poichéisingolidispositiviavrannocomunquenomihostprivati,questasoluzionepotrebbeesserepiùappropriatarispettoall'utilizzodiunaCApubblica. I certificati Intranet sono disponibili ( ma sono in fase di eliminazione ), ma poiché richiedono un nome di dominio completo o un indirizzo IP, i clienti dovrebbero aggiornali sul dispositivo.

Vedi questo articolo per tutti i dettagli su come questo funziona.

No, e ci sono diversi motivi per questo:

• Un certificato contiene non solo informazioni sul proprietario, ma contiene la sua chiave pubblica. La chiave privata corrispondente è nota solo al proprietario del certificato e, utilizzando la crittografia a chiave pubblica, è possibile verificare che l'endpoint della connessione SSL sia realmente il proprietario (o almeno quello che ha la chiave privata). Il certificato stesso è firmato da un'agenzia di certificati attendibile dal browser (tutto ciò è semplificato). Ma la forza crittografica di tutto questo dipende dalla dimensione delle chiavi e dagli algoritmi utilizzati. L'aumento delle dimensioni rende tutto più lento, meno dimensioni rende tutto meno sicuro. E poiché i computer diventano esperti più veloci e criptati solo migliori e trovano nuovi modi per rompere un algoritmo, la protezione crittografica del certificato si indebolisce con il tempo. Pertanto, ogni certificato deve scadere prima che la protezione si indebolisca.

• Un certificato potrebbe essere compromesso, ad es. alcuni cattivi o agenzie potrebbero ottenere la chiave privata e quindi identificarsi come proprietario o decifrare tutto il traffico. In questo caso il certificato viene revocato e le informazioni di revoca sono rese accessibili al pubblico. Se il certificato non scade mai, queste informazioni dovrebbero essere conservate per sempre e lo spazio di archiviazione necessario e il tempo di controllare un certificato di revoca aumenterebbe. In questo modo, i certificati di utenti finali più economici hanno una scadenza più breve rispetto ai certificati più costosi, perché gli utenti di basso costo probabilmente non proteggono la loro chiave privata, quindi è bene che le loro revoche possano essere gettate via dopo la data di scadenza. / p>

RFC 5280, Sezione 4.1.2.5 ("Validità") risponde tecnicamente alla tua domanda esattamente.

In breve, un certificato con una data di scadenza di 99991231235959Z (23:59 GMT del 31 dicembre 9999) soddisfa i tuoi requisiti esatti, ma RFC 5280 richiede anche che tu debba essere in grado di revocare quel certificato per rompere il percorso di certificazione (cioè revocando il certificato) prima di questa data.

Anche la data di scadenza è considerata come una data in cui l'utente dovrebbe verificare se le misure tecniche in vigore soddisfano ancora gli standard attuali (ad esempio se devono passare dal modulo lungo 1024 bit al modulo lungo 2048 bit o aggiornare il proprio server da DES a AES).

Per lo stesso motivo, le AC commerciali accettano di non emettere certificati per più di 3 anni nel futuro e richiedono nomi DNS pubblicamente risolvibili nello spazio pubblico IP; molto probabilmente, entrambi questi requisiti sono bloccanti per te.

Quindi alla fine ci sono solo due opzioni:

• diventa la tua CA root e rilascia automaticamente tali certificati. Una politica per emettere certificati "per sempre" non soddisfa le considerazioni sulla sicurezza dei fornitori di browser e sistemi operativi, quindi in definitiva ciò richiederà agli utenti di importare manualmente la CA principale. Consigliare agli utenti di fidarsi della CA principale è un'operazione delicata e potrebbe non trovare una buona accettazione tra i propri utenti. La CA potrebbe utilizzare restrizioni di nome x509 (quindi i certificati emessi sono validi solo per alcuni domini o subnet IP), ma tutti coloro che hanno una certa sicurezza in mente continueranno a chiedersi se è una buona idea andare in quella direzione. In breve: questo può diventare molto complesso, complicato e rischioso - non farlo.

• in fase di fabbricazione o "ripristino delle impostazioni di fabbrica", genera una singola chiave privata su e / o per ogni dispositivo e emette un certificato autofirmato con una data di scadenza, ad es. 10 anni nel futuro (o la data speciale di cui sopra). La documentazione deve chiedere agli utenti di rimuovere i certificati precedentemente installati dopo "ripristinare le impostazioni di fabbrica" e di importare quel certificato specifico per evitare l'avvertimento del browser. Karma extra per spiegare all'utente perché questo deve essere fatto:)

Fai attenzione quando usi la data "per sempre", il certificato potrebbe comunque diventare "meno sicuro" o "non valido". Ad esempio, i browser e i sistemi operativi dettano un keylength minimo o algoritmi (interrotti) per rifiutare e aggiornare tali requisiti di conseguenza. Al momento, i 1024 bit possono "funzionare", ma i browser iniziano a visualizzare le connessioni utilizzando meno 2048 bit per essere "non sicuro" o "non valido". E gli algoritmi si interrompono anche al punto in cui i browser non si fidano più di loro. Se il tuo certificato autofirmato fa uso di questo, dovrai aggiornarlo di conseguenza.