Un certificato "deve" avere esattamente le caratteristiche che i verificatori cercheranno. Un "verificatore" è qualsiasi sistema che guarderà la tua firma e il certificato e cercherà di decidere se la firma è accettabile.
La maggior parte dei verificatori che gestiscono certificati X.509 applicano le regole imposte dallo standard X.509 e Profilo X.509 di Internet . Ci sono molte di queste regole; i più importanti sono:
- Un verificatore dovrà creare un percorso (o catena ) in arrivo per una chiave pubblica che conosce a priori (il fiducia ancora ) fino al certificato di entità finale , che è il certificato contenente la chiave pubblica associata alla chiave privata utilizzata per firmare il documento XML.
- All'interno del percorso, ogni certificato (tranne l'ultimo) viene utilizzato per verificare la firma sul prossimo certificato. Ciascun certificato di questo tipo deve avere l'estensione del vincolo di base con il set di bit "CA", che contrassegna il certificato come una CA, ovvero adatto a verificare una firma sul certificato successivo nel percorso. Normalmente, la CA commerciale rifiuta di emettere certificati con il set di bit CA, oppure lo fa a un prezzo pesante, quindi è probabile che il "certificato sul computer di costruzione" sia non un certificato CA.
- Qualsiasi certificato può avere un'estensione Uso chiave, che specifica gli utilizzi consentiti per la chiave pubblica nel certificato. Per interoperare correttamente con i comuni verificatori, un certificato EE utilizzato per firmare un documento XML dovrebbe avere un'estensione Utilizzo chiave con i flag
digitalSignature e nonRepudiation impostati (o nessuna estensione Utilizzo chiave). Se un certificato è "un certificato SSL" o un "certificato di firma del codice" o qualsiasi altro nome di questo tipo, è principalmente una questione di quali flag sono impostati nell'estensione Uso chiave.
- E, naturalmente, il certificato EE dovrebbe ospitare una chiave pubblica adatta per la firma di cose, ad esempio RSA, DSA, ECDSA ... ma non Diffie-Hellman.
Il punto importante è che concatenare il "certificato incorporato" al "certificato macchina build" ha senso solo se si desidera che le firme XML siano verificabili dai verificatori generici, che non conoscono la propria specifica applicazione e utilizzano un generico set di trust ancore (incluso quello che ti ha venduto il tuo "build machine certificate"). È probabile che non funzioni, perché è improbabile che il tuo "certificato macchina build" abbia il bit "CA" impostato. Per controllare il contenuto di un certificato, usa OpenSSL : lo strumento da riga di comando (già incluso in MacOS X, qualsiasi buon Linux o * BSD e disponibile per lo strumento Windows) può essere utilizzato in questo modo:
openssl x509 -text -noout -in cert.pem
openssl x509 -text -noout -inform DER -in cert.crt
(usa il primo se il certificato è in formato PEM, il secondo se è in DER o prova entrambi).
Se controlli i verificatori (cioè nella tua applicazione, il sistema che verificherà la firma sul documento XML sarà un software che tu fornirà anche), quindi collegando il certificato della macchina di compilazione alla CA commerciale è inutile; staresti meglio creando la tua CA e facendo certificati. OpenSSL può farlo, oppure potresti optare per una soluzione più grafica come EJBCA .
Non faccio deliberatamente alcuna affermazione sulla solidità del concetto di "incorporamento sicuro di un certificato".