În depozitul de chei Java, dev64
Am continua acest lucru în subiectul anterior post-SSL. Acest post este despre terminologia legată de SSL în bibliotecile Java. El a început de post, ca traducerea articolului Java SSL Elemente de bază. Originalul, cu toate acestea, nu sa terminat, așa că m-am lăsat să se abată de la originalul.
Ce este un Java depozit de chei?
Keystore este utilizat pentru a stoca propria cheie și certificat de server privat sau client.
Pentru autentificarea client și server conexiuni SSL necesită chei private și certificate. Dacă utilizați autentificarea-un singur fel, depozitul de chei este necesară numai pe partea de server. În cazul în care autentificarea reciprocă și client și server de schimb de certificate, respectiv, și serverul, iar clientul trebuie să fie cu o pereche de chei de o cheie de chei private / publice + certificat.
Ie cu alte cuvinte, depozit de chei utilizate pentru stocarea cheilor și a certificatelor, utilizate pentru identificarea proprietarului cheie (client sau server).
Al doilea tip de depozit de chei este utilizat pentru a stoca certificate de încredere. Este pus cheile de încredere autorități de certificare CA. Atunci când se utilizează un certificat auto-semnat în magazin de încredere în sine poate pune un certificat auto-semnat. Aceasta este, de asemenea, un depozit de chei, dar în Java este numit un magazin de încredere.
Formatele suportate de Java depozitul de chei
astfel așa cum este descris mai sus, keystore - container utilizat pentru stocarea cheilor și certificatelor. Java acceptă două format keystore:
- JKS (Java Key Store) - format Java
- PKCS12 - acesta este un standard industrial
Tastați keystore, utilizați implicit, specificate în proprietățile de securitate Java fișier de proprietate keystore.type. În cazul în care aplicația accesează fișierul depozitului de chei fără a specifica în mod explicit tipul său, utilizat în format JKS. Java fișier de proprietăți de securitate este localizat în directorul lib din directorul de instalare cu Java pe drum: /lib/security/java.security
Pentru a lucra cu Java în depozitul de chei de distribuție au keytool speciale de utilitate. suficient pentru operațiuni cu cheile în Java keytool. Cu toate acestea, formatul este JKS propietarnym și închis. Prin urmare, de multe ori pentru diferite conversii și de a interacționa cu dezvoltatorii terțe părți pot fi folosite utilități furnizate cu biblioteca OpenSSL.
În cazul în care intenționați să le utilizați numai cheile în Java keystore în format JKS este bine.
Keystore (cel puțin în format JKS) poate stoca mai multe perechi de chei și certificate. Pentru identificarea fiecărei perechi individuale sau alias certificatul utilizat. Alias specificate în codul sursă pentru accesul la cheia sau certificatul corespunzător. Accesul la fiecare alias este restricționat prin parolă.
Procesul de generare a depozitului de chei (JKS sau PKS12) include generarea unei perechi de chei (publice și private). Apoi a primit de la autoritate de certificare (CA) pentru a semna cheia publică și informații de identificare asociate sub forma unui certificat. autoritate de certificare generează un certificat pe baza unui public de informații cheie și de identificare transmise într-un CSR.
Wikipedia spune că CA emite un certificat care se leagă cheia publică la numele distinctiv specificat (acesta poate fi un nume de gazdă (nume de gazdă, numele de utilizator sau numele aplicației) pentru a crea un Pași depozit de chei reprezintă utilizatorul sau aplicația gazdă sunt după cum urmează .:
1) Generarea o pereche de chei (cheie publică / privată)
În Java atunci când generează o pereche de chei folosind keytool crea imediat un certificat de auto-auto-semnat, care pot fi utilizate imediat pentru testare. Următorii pași, astfel încât trebuie doar pentru a crea un certificat oficial cu drepturi depline.
2) Generarea o cerere de (cerere de semnare a certificatului (CSR) certificat).
3) Ia CSR, semnat de un CA de încredere (de ieșire este un certificat)
4) Certificatul de import, CA realizat în magazinul dvs. cheie.
5) Import certificatul CA din truststore ca un certificat de încredere
Java implicit depozit de chei
server de web sau aplicație poate fi folosit pentru a spune Java fișier depozit de chei specificat proprietăți de instalare javax.net.ssl.keyStore. (Calea către fișierul keystore). În cazul în care cererea nu specifică proprietatea keystore, apoi porniți keystore implicit. Keystore implicit stocate în .keystore fișier în directorul home al utilizatorului este la rândul său, determinată de proprietatea de sistem user.home.
Implicit Java Truststore
Aplicația poate specifica pentru a utiliza un anumit Java truststore proprietăți de instalare fișier javax.net.ssl.trustStore. În cazul în care cererea nu specifică în mod clar truststore, atunci implicit este depozitul de încredere încărcat și utilizat. java truststore implicit este localizat în mod implicit în / lib / security / cacerts și parola: 'changeit'. truststore fișiere - fișierul care conține de obicei depozit de chei unul sau certificat CA ridicat de încredere (certificate de autorizare).
Pentru a facilita crearea și gestionarea fișierelor de distribuție Java în depozit de chei include utilitarul keytool. permițându-vă să creați fișiere JKS. Keytool vă permite să gestionați certificate și perechi de chei private publice.
Cu opțiunea -genkey, keytool generează o nouă pereche de chei publice / private, și creează un certificat auto-semnat pentru cheia publică.
keytool -genkey -keystore server.jks -dname "CN = localhost, OU = dev64, O = dev64-wordpress, L = Necunoscut, ST = Necunoscut, C = RU" -storepass storepass -alias server de test -keypass serverpass
Certificatul este creat în formatul X.509. În acest format, în calitate de proprietar ID-ul utilizat distinși Numele sau pur și simplu DN în format X.500. Exact același format de identificare obiect este utilizat, cum ar fi LDAP-protocol sau SNMP. Numele distinși este definit ca o virgulă separate atribute: «CN = Andrey Chesnokov, OU = dev64, O = dev64-wordpress, L = Necunoscut, ST = Necunoscut, C = RU». Aici, atributele individuale sunt decodificate după cum urmează:
- NC - denumirea comună numele proprietarului
- OU - organizationUnit (de exemplu, departament sau divizie) departament sau divizie
- O - ORGANIZATIONNAME - numele organizației de mare, de exemplu «ABCSystems, Inc.»
- L - localityName - localitate (oraș) numele, de ex «Palo Alto» locație (oraș)
- ST - statename - stat sau provincie numele, de ex «California»
- C - țară - cod de țară din două litere, de ex «CH»
Unele dintre atributele pot fi omise, în acest caz, este setat la necunoscut. La generarea test de chei, orice valori pot fi atribuite. Când primiți un certificat oficial de date sunt reglementate și inspectate de organizare autoritate de certificare.
În interiorul fiecărui certificat este stocat în format X.509 pereche denumiri Distinqueshed (DN), unul DN aparține titularului certificatului, iar al doilea indică identificatorul DN CA, a semnat certificatul. În cazul unui certificat auto-semnat, atât DN indică titularul certificatului.
Numele distinși este definită folosind opțiunea keytool -dname. Dacă DNAME opțiune nu este specificată, atunci keytool va solicita toate câmpurile obligatorii din linia de comandă.
Această opțiune specifică numele fișierului keystore keystore. Dacă vă dor, atunci keytool va crea un fișier numit .keystore în directorul home al utilizatorului.
Accesul la depozitul de chei este protejat de o parolă. Prin urmare opțiunea -keypass specifică parola pentru a accesa keystore ca întreg. Această parolă este necesară pentru a citi sau modifica oportunitățile de depozite de chei.
A doua parolă, așa cum sa menționat mai sus, este necesară pentru a avea acces la un anumit alias în keystore. Această a doua parolă este indicată de opțiunea -keypass.
astfel cu o singură comandă, se întoarce cu o pereche de chei de chei și certificate, depozitul este de a lua și pune-l în directorul corect pentru programul. Dar asta e altă poveste.
Ar trebui să verificați cu siguranta documentația oficială privind keytool, conține o mulțime de informații utile.