Chiarimento necessario per il processo di firma CSR

Question

Chiarimento necessario per il processo di firma CSR

#1 da (3 voti)

3

Non sembrano esserci molte informazioni approfondite sul processo di firma del certificato diverse da:

Guida all'uso del protocollo di interoperabilità di Gestione delle chiavi Versione 1.2 (PDF)
RFC 2986 - PKCS # 10: specifica sintassi della richiesta di certificazione, versione 1.7

Ecco un esempio di CSR che ho creato:

Ho incollato quanto sopra in certlogik.com e ho esaminato l'output.

Se ho capito bene, 4 componenti costituiranno CertificationRequestInfo :

Versione
Soggetto
Informazioni chiave pubblica
Attributi

Suppongo che utilizzando SHA1 o SHA2, il CertificationRequestInfo sia quindi sottoposto a hash e che l'output dell'hash sia crittografato utilizzando la chiave privata del computer che sta creando il CSR.

Quando arriva alla CA, la CA prende CertificationRequestInfo e esegue un hash su di essa. Quindi prende anche il valore crittografato e prova a decodificarlo utilizzando la chiave pubblica nel CSR. Se l'output dell'hash e l'output dell'hash decrittografati corrispondono, la CA firmerà il CSR.

Per favore correggimi se ho torto con quanto sopra. A questo punto sono confuso riguardo a quali dati la CA effettivamente segni (quali dati l'hash della CA e quindi crittografa quell'hash).

public-key-infrastructure certificates certificate-authority

posta Daniel 24.02.2015 - 23:38

fonte

1 risposta

Leggi altre domande sui tag public-key-infrastructure certificates certificate-authority

EMV come tecnologia di autenticazione e non una tecnologia di sicurezza dei dati Sicurezza della lettura di articoli tramite un lettore RSS

score 3 · Accepted Answer

La CSR è verificata per la validità. Se è valido, la vecchia firma viene eliminata e viene creato un nuovo certificato.

Gli ingredienti per il nuovo certificato sono i seguenti:

Informazioni dal CSR (più alcuni campi aggiunti / modificati / rimossi. Qualunque sia la tua CA è la migliore.)
Tipicamente alcuni vincoli di base (come la dichiarazione: "Quello che sto firmando qui è (o non è) supposto essere una CA stessa.")
Informazioni su chi sta firmando.
E poi la firma stessa.

Tutti i pezzi che devono essere firmati costituiscono un set. Questo set si chiama "TBSCertificate".
E TBSCertificate + parti della firma costituiscono ciò che viene chiamato "Certificato".

RFC 5280 si interrompe in questo modo:

Certificate  ::=  SEQUENCE  {
    tbsCertificate       TBSCertificate,
    signatureAlgorithm   AlgorithmIdentifier,
    signatureValue       BIT STRING  }

TBSCertificate  ::=  SEQUENCE  {
    version         [0]  EXPLICIT Version DEFAULT v1,
    serialNumber         CertificateSerialNumber,
    signature            AlgorithmIdentifier,
    issuer               Name,
    validity             Validity,
    subject              Name,
    subjectPublicKeyInfo SubjectPublicKeyInfo,
    issuerUniqueID  [1]  IMPLICIT UniqueIdentifier OPTIONAL,
                         -- If present, version MUST be v2 or v3

    subjectUniqueID [2]  IMPLICIT UniqueIdentifier OPTIONAL,
                         -- If present, version MUST be v2 or v3
    extensions      [3]  EXPLICIT Extensions OPTIONAL
                         -- If present, version MUST be v3
    }

C'è un eccellente post sul blog che approfondisce ciò che è e ciò che non è in realtà all'interno di un certificato: Morgan Simonsen, 2013-04-16, Capire le impronte digitali dei certificati digitali X.509 ( Archiviato qui )