Questo non è per "certificati superiori all'entità finale" ma solo per "certificati radice".
In puro X.509 , non esiste un "certificato radice". Esistono certificati e ci sono trust anchors . Un certificato contiene una chiave pubblica, il nome dell'entità che possiede quella chiave e è firmata da un'altra entità (una "autorità di certificazione superiore"). Questo processo di firma deve iniziare da qualche parte, e quella da qualche parte è un "punto di riferimento". Un'ancora di fiducia è un nome e una chiave pubblica.
X.509 non specifica in che modo un'entità dovrebbe codificare gli ancoraggi di trust, dal momento che i trust ancore sono qualcosa che è noto a priori , non qualcosa che deve essere scambiato sulla rete. Tuttavia, un metodo tradizionale per l'archiviazione di trust ancore consiste nell'utilizzare lo stesso formato dei certificati. Un certificato contiene, tra le altre cose, un campo non facoltativo per una firma da qualche CA superiore. Invece di definire un nuovo formato per un'ancora di fiducia, Tradition deve riempire il "campo firma" con un'auto-firma. Così nasce un certificato radice : un'ancora di trust codificata come certificato autofirmato.
Ma quella firma di sé non ha senso! Non ha alcun valore di sicurezza. Corrispondentemente, nessuno lo verifica (*). Pertanto, non vi è alcun problema relativo al suo uso di una funzione di hash che è altrimenti considerata con qualche sospetto.
(*) Alcuni sistemi controllano euristicamente tale firma perché i certificati autofirmati possono solo essere usati come root, non come altro. Ma questa non è una funzionalità di sicurezza; questo è per comodità di interfaccia utente, senza fare affidamento sulla sicurezza di quella firma. Quindi, nessun problema con SHA-1 o, come potrebbe, MD5 o MD2.