Stai visualizzando la documentazione di Apigee Edge.
Vai alla sezione
Documentazione di Apigee X. Informazioni
Questo documento descrive come creare, modificare ed eliminare archivi chiavi e archivi attendibili per Edge per il cloud privato versione 4.17.09 e precedenti.
Informazioni su archivi chiavi e archivi attendibili
Gli archivi chiavi e gli archivi attendibili definiscono repository di certificati di sicurezza utilizzati per TLS la crittografia. La differenza principale tra i due è dove vengono utilizzati nell'handshake TLS di elaborazione:
- Un keystore contiene un certificato TLS e una chiave privata utilizzata per identificare
durante l'handshake TLS.
Nel protocollo TLS unidirezionale, quando un client si connette all'endpoint TLS sul server, l'archivio chiavi del server presenta il certificato del server (certificato pubblico) al client. Il client verifica quindi che con un'autorità di certificazione (CA), come Symantec o VeriSign.
Nel sistema TLS a due vie, sia il client che il server gestiscono un archivio chiavi con i propri certificati e chiave privata utilizzata per l'autenticazione reciproca. - Un truststore contiene certificati utilizzati per verificare i certificati ricevuti come
nell'ambito dell'handshake TLS.
In TLS unidirezionale, non è necessario un archivio attendibilità se il certificato è firmato da una CA valida. Se sia firmato da una CA valida, il client invia una richiesta. alla CA per autenticare il certificato. In genere un client TLS utilizza un archivio attendibilità per convalidare certificati autofirmati ricevuti dal server TLS o certificati che non sono firmati da CA attendibile. In questo scenario, il client compila il suo archivio di attendibilità con i certificati che trust. Quando il client riceve un certificato del server, il certificato in entrata viene convalidate in base ai certificati nel relativo archivio attendibilità.
Ad esempio, un client TLS si connette a un server TLS in cui il server utilizza un modello certificato. Poiché si tratta di un certificato autofirmato, il client non può convalidarlo con una CA. Il client precarica invece il certificato autofirmato del server nel proprio archivio di attendibilità. Poi, quando il client tenta di connettersi al server, il client utilizza il suo truststore per convalidare il certificato ricevuto dal server.
Per il protocollo TLS bidirezionale, sia il client TLS sia il server TLS possono utilizzare un archivio attendibilità. Un archivio attendibilità quando si esegue il protocollo TLS a due vie quando Edge agisce come server TLS.
I certificati possono essere emessi da un'autorità di certificazione (CA) o autofirmati dal chiave privata generata da te. Se hai accesso a una CA, segui le istruzioni fornite dal tuo CA per la generazione di chiavi e l'emissione di certificati. Se non hai accesso a una CA, puoi generare un certificato autofirmato utilizzando uno dei numerosi strumenti senza costi disponibili pubblicamente, come openssl.
L'implementazione di un un archivio chiavi e un archivio attendibilità su Edge
Su Edge, un archivio chiavi contiene uno o più file JAR, dove il file JAR contiene:
- Certificato TLS come file PEM: un certificato firmato da un'autorità di certificazione (CA), una catena di certificati in cui l'ultimo certificato è firmato da una CA o un certificato autofirmato certificato.
- Chiave privata come file PEM. Edge supporta dimensioni di chiavi fino a 2048 bit. La passphrase è facoltativo.
Un archivio attendibilità è simile a un archivio chiavi, tranne per il fatto che contiene solo certificati come file PEM, ma non e le chiavi private.
Se il certificato fa parte di una catena, l'archivio chiavi/truststore deve contenere tutti i certificati in come singoli file PEM o come file singolo. Se utilizzi un singolo file, il parametro i certificati devono essere nell'ordine in cui il primo certificato nel file è quello utilizzato per TLS seguito dalla catena di certificati, in ordine al certificato CA. Devi inserire una riga vuota tra ogni certificato nel file.
Edge fornisce un'API che puoi utilizzare per creare archivi chiavi e archivi attendibili. Le API effettive sono in modo analogo. La differenza è che quando si crea un archivio chiavi, si passa un file JAR che contiene e una chiave privata. Quando crei un archivio attendibilità, passi solo il certificato come file PEM.
Informazioni sul formato file di certificato e chiave
Gli esempi in questo documento mostrano il certificato e la chiave TLS definiti come file PEM, che sono conformi con il formato X.509. Se il certificato o la chiave privata non è definito da un file PEM, puoi convertire in un file PEM utilizzando utilità come Opensl.
Tuttavia, molti file .crt e .key sono già in formato PEM. Se questi file contengono testo e sono racchiusi in:
-----BEGIN CERTIFICATE----- -----END CERTIFICATE-----
oppure:
-----BEGIN ENCRYPTED PRIVATE KEY----- -----END ENCRYPTED PRIVATE KEY-----
I file sono quindi compatibili con il formato PEM e puoi utilizzarli in un archivio chiavi il truststore senza convertirli in un file PEM.
Se hai una catena di certificati e vuoi utilizzarla in un archivio chiavi o un archivio attendibilità, puoi combinare tutti i certificati in un unico file PEM con una nuova riga tra un certificato e l'altro. La i certificati devono essere in ordine e l'ultimo deve essere un certificato radice o un certificato intermedio firmato da un certificato radice:
-----BEGIN CERTIFICATE----- (Your Primary TLS certificate) -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- (Intermediate certificate) -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- (Root certificate or intermediate certificate signed by a root certificate) -----END CERTIFICATE-----
Visualizza i dettagli di un archivio chiavi esistente
Verifica la presenza di archivi chiavi esistenti nell'ambiente utilizzando la funzione Elenca archivi chiavi e Truststores:
curl -X GET \
https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores \
-u email:password
Per i clienti cloud, viene fornito un archivio chiavi predefinito per le organizzazioni di prova senza costi sia nel ambienti di test e produzione. Dovresti vedere i seguenti risultati per questa chiamata ambienti:
[ "freetrial" ]
Puoi usare questo archivio chiavi predefinito per testare le tue API ed eseguirne il push in produzione, di solito crea il tuo archivio chiavi, con il tuo certificato e la tua chiave, prima del deployment in produzione.
Per i clienti del cloud privato, l'array restituito è vuoto finché non crei il primo un archivio chiavi.
Controlla i contenuti dell'archivio chiavi utilizzando la funzione Ottieni un'API Keystore o Truststore. Per un cliente cloud, dovresti vedere un singolo server TLS il certificato predefinito fornito da Apigee Edge per gli account di prova senza costi.
curl https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores/freetrial \
-u email:password
La risposta dovrebbe apparire come:
{
"certs" : [ "wildcard.apigee.net.crt" ],
"keys" : [ "freetrial" ],
"name" : "freetrial"
}
Puoi visualizzare queste informazioni anche nell'interfaccia utente di gestione perimetrale:
- Accedi alla UI di gestione Edge all'indirizzo https://enterprise.apigee.com (cloud) o
http://<ms-ip>:9000(on-premise), dove<ms-ip>è l'IP del server di gestione. - Nel menu dell'interfaccia utente di gestione perimetrale, seleziona Amministratore > certificati TLS.
Ottieni dettagli del certificato TLS
Puoi utilizzare lo Recupera i dettagli della certificazione da un archivio chiavi o un archivio attendibilità per visualizzare i dettagli sui certificati TLS in l'archivio chiavi, come la data di scadenza e l'emittente. In primo luogo, ottieni il nome del certificato in che ti interessa. Questo esempio recupera le informazioni per l'archivio chiavi chiamato "prova senza costi".
curl https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores/freetrial \
-u email:password
Esempio di risposta:
{
"certs" : [ "wildcard.apigee.net.crt" ],
"keys" : [ "freetrial" ],
"name" : "freetrial"
}
Quindi, utilizza il valore della proprietà certs per ottenere i dettagli del certificato:
curl https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores/freetrial/certs/wildcard.apigee.net.crt \
-u email:password
Esempio di risposta:
{
"certInfo" : [ {
"expiryDate" : "Wed, 23 Apr 2014 20:50:02 UTC",
"isValid" : "Yes",
"issuer" : "CN=Go Daddy Secure Certificate Authority - G2, OU=http://certs.godaddy.com/repository/, O="GoDaddy.com, Inc.", L=Scottsdale, ST=Arizona, C=US",
"subject" : CN=*.example.apigee.net, OU=Domain Control Validated",
"subjectAlternativeNames" : ["*.example.apigee.net","*.example.apigee.net" ],
"validFrom" : "Tue, 15 Apr 2014 09:17:03 UTC",
"version" : 3
} ],
"name" : "example.apigee.net.crt"
}
Puoi visualizzare queste informazioni anche nell'interfaccia utente di gestione perimetrale:
- Accedi alla UI di gestione Edge all'indirizzo https://enterprise.apigee.com (cloud)
o
http://<ms-ip>:9000(on-premise), dove<ms-ip>è l'IP del server di gestione. - Nel menu dell'interfaccia utente di gestione perimetrale, seleziona Amministratore > TLS certificati.
Nella UI di Edge, puoi specificare l'anticipo con cui Edge indica che un certificato in scadenza. Per impostazione predefinita, l'interfaccia utente evidenzia tutti i certificati la cui scadenza è prevista nei prossimi 10 giorni.
Crea un archivio chiavi
Un archivio chiavi è specifico per un ambiente nella tua organizzazione, ad esempio il set di dati completamente gestito di Google Cloud. Pertanto, se vuoi testare l'archivio chiavi in un ambiente di test prima di eseguire il deployment, nell'ambiente di produzione, devi crearla in entrambi gli ambienti.
La creazione di un archivio chiavi è un processo in due fasi:
- Crea un file JAR contenente il certificato e la chiave privata.
- Creare l'archivio chiavi e caricare il file JAR.
Creare un file JAR contenente il certificato e la chiave privata
Crea un file JAR con la chiave privata, il certificato e un manifest. Il file JAR deve che contengono i seguenti file e directory:
/META-INF/descriptor.properties myCert.pem myKey.pem.
Nella directory contenente la coppia di chiavi e il certificato, crea una directory denominata
/META-INF. Quindi, crea un file
chiamato descriptor.properties in
/META-INF con quanto segue
contenuti:
certFile={myCertificate}.pem
keyFile={myKey}.pem
Genera il file JAR contenente la coppia di chiavi e il certificato:
jar -cf myKeystore.jar myCert.pem myKey.pem
Aggiungi descriptor.properties al file JAR:
jar -uf myKeystore.jar META-INF/descriptor.properties
Creare l'archivio chiavi e caricare File JAR
Per creare un archivio chiavi in un ambiente, devi solo specificare il nome dell'archivio chiavi nella Crea un'API Keystore o Truststore. Il nome può contenere solo caratteri alfanumerici:
curl -X POST -H "Content-Type: text/xml" \
https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores \
-d '<KeyStore name="myKeystore"/>' -u email:password
Esempio di risposta:
{
"certs" : [ ],
"keys" : [ ],
"name" : "myKeystore"
}
Dopo aver creato un archivio chiavi denominato in un ambiente, puoi caricare i file JAR contengono un certificato e una chiave privata utilizzando Carica un file JAR in un'API Keystore:
curl -X POST -H "Content-Type: multipart/form-data" \
-F file="@myKeystore.jar" -F password={key_pass} \ "https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores/{myKeystore}/keys?alias={key_alias}" \
-u email:password
dove l'opzione -F specifica
il percorso del file JAR.
In questa chiamata, specificherai due parametri di query:
alias- Identifica il e la chiave nell'archivio chiavi. Quando crei un host virtuale, fai riferimento e la chiave con il nome alias.password- La password per la chiave privata. Ometti questo parametro se la chiave privata non ha password.
Verifica che l'archivio chiavi sia stato caricato correttamente:
curl https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores/myKeystore \
-u email:password
Esempio di risposta:
{
"certs" : [ "myCertificate" ],
"keys" : [ "myKey" ],
"name" : "myKeystore"
}
Crea un archivio attendibilità
Le API che utilizzi per creare un archivio attendibili sono le stesse che utilizzi per creare un archivio chiavi. La l'unica differenza è che passi il file del certificato come file PEM anziché come file JAR.
Se un certificato fa parte di una catena, devi caricare tutti i certificati della catena separatamente.
all'archivio attendibilità o creare un unico file contenente tutti i certificati, includi una nuova riga tra
ogni certificato nel file. In genere il certificato finale è firmato dall'emittente del certificato. Per
ad esempio, nell'archivio attendibili, carichi un certificato client, client_cert_1, e il certificato client
certificato dell'emittente, ca_cert.
Durante l'autenticazione TLS a due vie, l'autenticazione client ha esito positivo quando il server invia
client_cert_1 al cliente come
parte del processo di handshake TLS.
In alternativa, hai un secondo certificato, client_cert_2, firmato dallo stesso certificato.
ca_cert. Tuttavia, non
carica client_cert_2 in
archivio attendibilità. L'archivio attendibilità contiene ancora client_cert_1 e ca_cert.
Quando il server supera client_cert_2 come parte dell'handshake TLS,
richiesta approvata. Questo perché Edge consente il completamento della verifica TLS quando client_cert_2 non esiste nel
archivio attendibilità ma è stato firmato da un certificato esistente nel truststore. Se rimuovi l'autorità di certificazione
certificato, ca_cert, del
truststore, la verifica TLS non va a buon fine.
Crea un archivio attendibilità vuoto nell'ambiente utilizzando Crea un Archivio chiavi o Truststore, la stessa API che utilizzi per creare un archivio chiavi:
curl -X POST -H "Content-Type: text/xml" -d \
'<KeyStore name="myTruststore"/>' \
https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores \
-u email:password
Carica il certificato come file PEM nel truststore utilizzando Carica un certificato in un'API Truststore:
curl -X POST -H "Content-Type: multipart/form-data" -F file="@trust.pem" \
https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores/myTruststore/certs?alias=myTruststore \
-u email:password
dove l'opzione -F specifica
del file PEM.
Elimina un archivio chiavi o un archivio attendibili
Puoi eliminare un archivio chiavi o un archivio attendibilità utilizzando la funzione Elimina un'API Keystore o Truststore:
curl -X DELETE \
https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores/myKeystoreName \
-u email:password
Esempio di risposta:
{
"certs" : [ ],
"keys" : [ ],
"name" : "myKeystoreName"
}
Se elimini un archivio chiavi o un archivio attendibilità utilizzato da un host virtuale o da una destinazione endpoint/target/server, tutte le chiamate API tramite l'host virtuale o l'endpoint/server di destinazione non riuscirà...