Potresti aver visto segnalazioni su un problema che sta interessando più autorità di certificazione, tra cui Apple, Google, GoDaddy e (purtroppo) SSL.com. La maggior parte di queste aziende utilizza un programma chiamato EJBCA (Enterprise Java Beans Certificate Authority) per una serie di attività CA. Come ha osservato Fotis Loukos, Director of Security Architecture di SSL.com:
"Il metodo di generazione dei numeri di serie da parte di EJBCA ha portato a una discrepanza tra il comportamento e l'output previsti ed effettivi, in modo tale che qualsiasi CA che utilizza EJBCA con le impostazioni predefinite incontrerà questo problema (e sarà quindi in violazione di BR 7.1)."
"BR 7.1" si riferisce alla sezione 7.1 dei requisiti di base del forum CA / B, che afferma:
"A partire dal 30 settembre 2016, le CA DEVONO generare numeri di serie di certificati non sequenziali maggiori di zero (0) contenenti almeno 64 bit di output da un CSPRNG."
CSPRNG è l'abbreviazione di "generatore di numeri pseudo-casuali crittograficamente sicuro" ed è il meccanismo utilizzato per generare numeri con sufficiente casualità (o "entropia") per garantire che siano sicuri e unici. Il metodo EJBCA ha scelto di utilizzare durante la generazione dei numeri di serie, tuttavia, imposta automaticamente il bit iniziale su zero, il che significa che in una stringa lunga 64 bit, il numero di serie conterrà solo 63 bit di output dal CSPRNG.
L'impatto di questo problema sulla sicurezza nel mondo reale è incredibilmente piccolo, ma anche se la differenza tra 63 e 64 bit di entropia non mette a rischio gli utenti di Internet, è comunque in violazione dei requisiti di SSL.com e di tutti gli altri affidabili Le CA osservano. Questo è il motivo per cui SSL.com revoca tutti i certificati interessati e rilascia certificati sostitutivi per tutti i clienti interessati.
I certificati sostitutivi saranno dello stesso tipo di quelli revocati e conterranno gli stessi nomi DNS. Inoltre, la durata di questi certificati sostitutivi sarà del intera durata del certificato acquistato originariamente. Ciò significa che anche se hai acquistato un certificato di un anno quattro mesi fa, il tuo nuovo certificato di sostituzione sarà valido per un anno intero dalla data del rilascio, per un totale di 16 mesi.
Infine, questo problema si applica esclusivamente all'SSL /TLS certificati (Basic, Premium, High Assurance, Enterprise EV, Wildcard e Multi-domain). Altri tipi di certificati, tra cui S/MIME, NAESB e la firma del codice non sono interessati in alcun modo.
