Chiarificazione dei certificati autofirmati rispetto all'autorità di certificazione principale

Question

Chiarificazione dei certificati autofirmati rispetto all'autorità di certificazione principale

#1 da (9 voti)
#2 da (1 voti)
#3 da (0 voti)
#4 da (0 voti)

9

Spero che qualcuno possa aiutarmi a capire alcune nozioni di base sui certificati SSL che ho riscontrato problemi con la raccolta di documenti, Wikipedia e praticamente ovunque su Internet.

Sto lavorando su un'applicazione che comunica con un altro su una rete separata. Ogni applicazione agisce sia come client che come server nella comunicazione bidirezionale. Utilizzeranno i servizi REST su HTTPS con il firewall di ciascuna rete aperto esplicitamente per l'altro. Tutti i certificati SSL saranno autofirmati. La mia applicazione è scritta in Java ma non sono sicuro dell'altra.

I credo Ho due opzioni per stabilire le connessioni HTTPS con certificati autofirmati:

Il framework sottostante di ogni applicazione (ad es. Java) installa il certificato autofirmato dell'altro, risultante in tale framework e non necessariamente nel SO più ampio, fidandosi del certificato
Ogni server installa il certificato dell'altro come autorità di certificazione principale e quindi si fida di qualsiasi certificato autofirmato prodotto dall'altro server. Un framework come Java dovrebbe riconoscere questa autorità di certificazione radice a livello di sistema operativo, ma un browser web su quel server potrebbe non tenere il proprio database

Il server su cui sto lavorando ha già generato i seguenti file: server.crt e server.key . Credo che questi siano generati usando openssl genrsa . Comprendo che .crt è il certificato pubblico e .key è la sua controparte a chiave privata. La mia domanda principale è

Il .crt può essere considerato come un certificato a livello di framework o un'autorità di certificazione radice a livello di OS dall'altro server (cioè posso scegliere come installarlo)? Nella mia ricerca online questo è stato molto confuso visto che molti termini sembrano sovraccarichi. Non posso dire se sto lavorando con un'autorità di certificazione o solo con un certificato regolare.
Se la risposta a 1 è no, che tipo di file devo generare dai file esistenti per installare solo il certificato autofirmato?

Qualsiasi aiuto è molto apprezzato e supponiamo che fornire collegamenti a pagine di Wikipedia non mi aiuti molto.

tls certificates certificate-authority

posta tomfumb 03.03.2015 - 04:16

fonte

4 risposte

1

Le due opzioni citate sono quasi corrette: tuttavia, puoi (e dovresti) installare certificati autofirmati senza che siano certificati Certificate Authority.

La differenza tra un certificato autofirmato e un certificato CA è che un certificato CA è uno speciale certificato autofirmato con i suoi "basicConstraints" impostati su "CA: true" (di solito con il flag critico impostato). Inoltre, la sequenza keyUsage di CAcert elenca "cRLSign" e "keyCertSign" come finalità che non devono essere presenti in un certificato regolare (non CA).

Ora alle tue due domande:

Puoi usarlo come certificato a livello di framework o di sistema operativo a tuo piacimento, ma non confondere i certificati autofirmati con i certificati CA (vedi sopra). Dal momento che il certificato sembra essere solo un certificato di scopo speciale per la tua applicazione, ti consiglio di usarlo come certificato a livello di framework. Inoltre, l'installazione di un certificato a livello di sistema operativo attendibile potrebbe richiedere privilegi di amministratore che non tutti i partner di comunicazione potrebbero avere.
N / A (poiché la risposta a 1. è sì :))

Nota a margine: il motivo per cui la distinzione tra certificati autofirmati CA e non CA è rilevante è che non si deve consentire a un certificato autofirmato, il cui scopo è quello di convalidare un partner di comunicazione, di fungere da certificato autorità poiché ciò potrebbe aprire ulteriori implicazioni sulla sicurezza (ad es. attacchi MITM che utilizzano detto certificato come autorità fidata).

risposta data 20.04.2016 - 11:46

fonte

0

Qui stai cercando di autenticarti e fidarti di entrambe le reti mentre agisci come bidirezionale. Il certificato dell'autorità fidata è diverso / uguale e il certificato di rilascio della CA può essere diverso o lo stesso non ha alcun problema su di esso.

Nota: non utilizzare certificati autofirmati per le comunicazioni SSL e seguire le regole RFC standard.

Se vuoi stabilire una comunicazione tra due reti ci sono molti modi. 1) Stabilimento del tunnel 2) PTP 3) basato su SSL: un. È sufficiente creare due CA diverse e posizionarle su reti e ogni certificato CA verrà inserito in ciascuna rete. Ora ogni CA dovrebbe rilasciare il certificato e verrà convalidato dal trust e la comunicazione sarà più sicura ora.

risposta data 03.03.2015 - 04:39

fonte

0

Cosa deve fare l'applicazione dopo aver configurato la connessione è controllare la validità del certificato ricevuto. Si potrebbe fare questo con un cenno al pki, cioè.

hai certificati CA sull'applicazione in grado di verificare l'emittente del certificato ricevuto

o

Un cert cert's emittente della cert, cioè stesso.

Molto dipende dal fatto che stai ruotando la tua libreria o in base a un'API.

risposta data 03.03.2015 - 06:57

fonte

Leggi altre domande sui tag tls certificates certificate-authority

Come determinare se un provider VPN rispetta la riservatezza dei dati? Vale la pena aumentare l'entropia / dev / random nel software?

score 9 · Accepted Answer

Dovresti vedere l'infrastruttura del certificato (ovvero PKI, Public Key Infrastructur) come una rete di fiducia.

Quando comunichi con più persone, che vogliono autenticarsi reciprocamente (e i loro siti web), devi prima scegliere una persona fidata comune. Questa terza persona diventa una "terza parte attendibile" e verrà chiamata "autorità di certificazione" (CA) ai fini della gestione dei certificati.

La CA creerà una chiave principale, nota anche come chiave CA principale. La chiave privata sarà tenuta segreta dal TTP a tutti i costi. La chiave pubblica verrà incorporata in un certificato e questo certificato sarà firmato dalla chiave pubblica della CA. Ciò significa che il certificato è autofirmato e che è possibile verificare la firma con la chiave al suo interno.

Supponiamo ora di voler accedere al sito web di Alice, ma vuoi che sia davvero il sito web di Alice e non un'altra persona che afferma di essere lei. Alice fa parte della tua comunità e quindi contatta la CA che hai accettato di utilizzare. Invia alla CA una CSR (Certificate Signing Request) che in pratica è una chiave pubblica. La CA esegue il processo di verifica che Alice sia Alice (ad esempio, la persona responsabile incontra Alice di persona e prende il CSR dalle sue mani). Quando la CA è sicura che Alice è Alice e il CSR appartiene a lei, la CA può creare un certificato nel nome di Alice e firmare questo certificato con la chiave privata della CA.

Quando ti connetti sul sito web di Alice, chiedi il certificato. Una volta ottenuto il certificato, si desidera verificare che sia il buono. È possibile vedere nel certificato che è stato emesso da una CA. Se hai la chiave CA puoi verificare la firma. Se ritieni che la CA stia facendo correttamente il suo lavoro, allora puoi fidarti che questo certificato è buono e dato che la CA si fida di aver autenticato Alice in primo luogo, allora puoi fidarti che questo certificato appartiene ad Alice.

Puoi quindi essere sicuro che la crittografia di un messaggio con questa chiave pubblica verrà letta solo da Alice che ha la chiave privata corrispondente. Sei anche sicuro che qualsiasi cosa scritta da questo certificato sia una firma fatta da Alice.

Se Alice vuole autenticarti in cambio, allora devi fare le stesse cose (ottenere un certificato firmato dalla CA, dato che Alice si fida della CA e si fiderà di questo certificato)

Nel tuo caso, dal momento che sembra che tu abbia padroneggiato tutti gli endpoint, potresti semplicemente creare due certificati autofirmati (che sono in realtà due certificati CA radice) e scambiare le parti pubbliche con l'altro endpoint. Ciascun endpoint utilizzerà la propria chiave privata per firmare le richieste in uscita e decrittografare i messaggi in arrivo e l'altro certificato endpoint per crittografare il messaggio in uscita e verificare i messaggi in arrivo.

Se ti capita di avere un sacco di endpoint, potrebbe valere la pena creare la tua CA. Generare un certificato CA radice quindi firmare il certificato per ciascun endpoint. In ogni endpoint è possibile installare il certificato CA radice pubblica. Quindi, ogni volta che un endpoint si connette a un altro, l'endpoint contattato può inviare il certificato e il chiamante può verificarlo rispetto al certificato CA di origine.

Il primo metodo ha il vantaggio di essere semplice, ma compromettere un certificato implica scambiarlo con uno nuovo su tutti gli endpoint. Il secondo metodo ha il vantaggio di essere scalabile, un endpoint non deve sapere quanti altri endpoint esistono poiché può comunque validare il certificato al volo. Inoltre, esiste un modo per gestire la compromissione delle chiavi con le liste di revoche dei certificati, ad esempio.