Questo documento descrive come creare, modificare ed eliminare i keystore e i truststore per Edge per il cloud e per Edge per il private cloud nelle versioni 4.18.01 e successive.
Nota: Private Cloud versione 4.17.09 e precedenti non consente di creare
Attenzione : quando un proxy API in Apigee Edge for Public
Il cloud privato si connette a un endpoint o a un server di destinazione, Apigee
non eseguire per impostazione predefinita la convalida del nome host per il certificato presentato dalla destinazione
endpoint o il server di destinazione. Per applicare la convalida del nome host, puoi scegliere tra applicare una configurazione a livello di singolo proxy o impostare un flag per attivare l'applicazione per l'intera organizzazione. Per ulteriori informazioni su queste modifiche alla configurazione, consulta il bollettino sulla sicurezza: GCP-2024-006 .
Informazioni su archivi chiavi/truststore e host virtuali per Edge Cloud
Il processo di creazione di archivi chiavi/truststore per Edge Cloud richiede di seguire tutte le
sull'uso degli host virtuali. Ad esempio, con gli host virtuali nel cloud:
Gli host virtuali devono utilizzare TLS.
Gli host virtuali possono utilizzare solo la porta 443.
Devi utilizzare un certificato TLS firmato. Non è consentito l'utilizzo di certificati non firmati con host virtuali nel cloud.
Il nome di dominio specificato dal certificato TLS deve corrispondere all'alias host dell'host virtuale.
Scopri di più :
Implementazione di archivi chiavi e truststore in
Edge
Per configurare la funzionalità che si basa su un'infrastruttura a chiave pubblica, come TLS, è necessario
e creare archivi chiavi e archivi attendibili che contengano le chiavi e i certificati digitali necessari.
In Edge, i keystore e i truststore sono entrambi rappresentati da un'entità keystore
che contengono uno o più alias . In altre parole, non esiste alcuna differenza di implementazione tra un keystore e un truststore su Edge.
La differenza tra i file keystore e truststore deriva dai tipi di voci che contengono e dal modo in cui vengono utilizzati nel handshake TLS:
keystore: un'entità keystore contenente uno o più
alias , in cui ogni alias contiene una coppia di certificati/chiavi.
truststore: un'entità keystore contenente uno o più
alias , in cui ogni alias contiene solo un certificato.
Quando configuri TLS per un host virtuale o un endpoint di destinazione, i keystore e i truststore svolgono ruoli diversi nella procedura di handshake TLS. Quando configuri un host virtuale o una destinazione
di sicurezza specifica, devi specificare archivi chiavi e archivi attendibili separatamente nell'<SSLInfo>
come mostrato di seguito per un host virtuale:
<VirtualHost name="myTLSVHost">
<HostAliases>
<HostAlias>apiTLS.myCompany.com</HostAlias>
</HostAliases>
<Interfaces/>
<Port>9006</Port>
<SSLInfo>
<Enabled>true</Enabled>
<ClientAuthEnabled>false</ClientAuthEnabled>
<KeyStore>ref://keystoreref</KeyStore>
<KeyAlias>myKeyAlias</KeyAlias>
</SSLInfo>
</VirtualHost>
In questo esempio specifichi il nome dell'archivio chiavi e dell'alias utilizzati dall'host virtuale per
il proprio archivio chiavi TLS. Utilizza un riferimento per specificare il nome del keystore in modo da poterlo modificare in un secondo momento alla scadenza del certificato. L'alias contiene una coppia certificato/chiave utilizzata per identificare l'host virtuale
a un client TLS che accede all'host virtuale. In questo esempio, non esiste un truststore
obbligatorio.
Se è necessario un archivio attendibilità, ad esempio per una configurazione TLS a due vie, utilizza
Tag <TrustStore>
per specificare l'archivio di attendibilità:
<VirtualHost name="myTLSVHost">
<HostAliases>
<HostAlias>apiTLS.myCompany.com</HostAlias>
</HostAliases>
<Interfaces/>
<Port>9006</Port>
<SSLInfo>
<Enabled>true</Enabled>
<ClientAuthEnabled>true</ClientAuthEnabled>
<KeyStore>ref://keystoreref</KeyStore>
<KeyAlias>myKeyAlias</KeyAlias>
<TrustStore>ref://truststoreref</TrustStore>
</SSLInfo>
</VirtualHost>
In questo esempio, il tag <TrustStore>
fa riferimento solo a un keystore e non specifica un alias specifico. Ogni alias nel keystore contiene un certificato o una catena di certificati che viene utilizzata nell'ambito della procedura di handshake TLS.
Formato
Caricamento di API e UI supportato
Supporto per i flussi in uscita
Convalidato
PEM
Sì
Sì
Sì
* PKCS12
Sì
Sì
Sì Nota: Apigee converte internamente PKCS12 in PEM.
* DER
No
No
Sì
* PKCS7
No
No
No
* Ti consigliamo di utilizzare PEM, se possibile.
Utilizzo di archivi chiavi PKCS12 con Edge per Private Cloud 4.53.00 o versioni successive
Se utilizzi Edge for Private Cloud 4.53.00 o versioni successive, devi utilizzare solo un keystore PKCS12 per caricare le chiavi e i certificati correlati in Apigee. Per assistenza con la conversione delle chiavi e dei certificati esistenti nel formato PKCS12/PFX, consulta la sezione Convertire i certificati in formato supportato .
Informazioni sull'implementazione di un alias
Nota : Apigee converte le chiavi e i certificati PKCS12 caricati nel formato PEM. Me
consigliamo di utilizzare solo file in formato PEM, se possibile.
Su Edge, un keystore contiene uno o più alias , in cui ogni
l'alias contiene:
Un certificato TLS come file PEM o PKCS12/PFX: un certificato firmato da un'autorità di certificazione (CA), un file contenente una catena di certificati in cui l'ultimo certificato è firmato da un'autorità di certificazione o un certificato autofirmato.
Chiave privata come file PEM o PKCS12/PFX. Edge supporta dimensioni delle chiavi fino a 2048 bit. Una passphrase è facoltativa.
In Edge, un truststore contiene uno o più alias , dove ogni alias contiene:
Un 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 un'autorità di certificazione o un certificato autofirmato.
Edge fornisce un'interfaccia utente e un'API che puoi utilizzare per creare archivi chiavi, creare alias, caricare coppie di certificati/chiavi e aggiornare i certificati. L'interfaccia utente e l'API che utilizzi per creare un truststore sono le stesse che utilizzi per creare un keystore. La differenza è che quando si crea un truststore, si creano anche alias
che contengono solo un certificato.
Puoi rappresentare certificati e chiavi come file PEM o come file PKCS12/PFX. I file PEM rispettano
nel formato X.509. Se il certificato o la chiave privata non è definito da un file PEM, puoi convertirlo in un file PEM utilizzando utilità come openssl
.
Tuttavia, molti file .crt e .key sono già in formato PEM. Se questi file sono file di 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 keystore o
truststore senza doverli convertire in un file PEM.
Informazioni sulle catene di certificati
Se un certificato fa parte di una catena, lo gestisci in modo diverso a seconda che venga utilizzato o meno in una
un archivio chiavi o in un archivio attendibilità:
Archivio chiavi : se un certificato fa parte di una catena, devi creare un singolo file contenente tutte le
certificati della catena. I certificati devono essere in ordine e l'ultimo deve essere un certificato radice o un certificato intermedio firmato da un certificato radice.
Truststore : se un certificato fa parte di una catena, devi creare un unico file contenente tutti i certificati e caricarlo in un alias oppure caricare tutti i certificati della catena separatamente nel truststore utilizzando un alias diverso per ogni certificato. Se li carichi come singolo certificato, i certificati devono essere in ordine e l'ultimo deve essere un certificato radice o un certificato intermedio firmato da un certificato radice.
Se crei un singolo file contenente più certificati, devi inserire una riga vuota tra ogni certificato.
Ad esempio, puoi combinare tutti i certificati in un unico file PEM. I certificati devono essere inseriti
e l'ultimo certificato deve essere un certificato radice o un certificato intermedio firmato da un certificato radice
certificato:
----- 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 -----
Se i certificati sono rappresentati come file PKCS12/PFX, puoi utilizzare il comando openssl
per creare un file PKCS12/PFX dalla catena di certificati, come mostrato di seguito:
openssl pkcs12 -export -out certificate.pfx -inkey privateKey.key -in certificate.crt -certfile CACert.crt
Quando si lavora con catene di certificati in un truststore, non è sempre necessario caricare
certificati della catena. Ad esempio, carichi un certificato client, client_cert_1
, e il certificato dell'emittente del certificato client, ca_cert
.
Durante l'autenticazione TLS bidirezionale, l'autenticazione del client riesce quando il server invia client_cert_1
al client nell'ambito della procedura di handshake TLS.
In alternativa, hai un secondo certificato, client_cert_2
, firmato dallo stesso certificato.
ca_cert
. Tuttavia, non carichi client_cert_2
nell'archivio attendibilità.
L'archivio attendibilità contiene ancora solo client_cert_1
e ca_cert
.
Quando il server passa client_cert_2
nell'ambito del handshake TLS, la richiesta viene completata. Questo perché Edge consente il completamento della verifica TLS quando client_cert_2
non esiste nel truststore, ma è stato firmato da un certificato presente nel truststore. Serimuovi il certificato CA ca_cert
dal truststore, la verifica TLS non va a buon fine.
Considerazioni relative a FIPS
Se utilizzi Edge for Private Cloud 4.53.00 o versioni successive su un sistema operativo compatibile con FIPS, devi utilizzare solo un keystore PKCS12 per caricare le chiavi e i certificati correlati in Apigee.
Esplorare la pagina Magazzini chiavi TLS
Accedi alla pagina Archivio chiavi TLS, come descritto di seguito.
Edge
Per accedere alla pagina delle caselle chiavi TLS utilizzando l'interfaccia utente di Edge:
Accedi a https://apigee.com/edge come amministratore dell'organizzazione .
Seleziona la tua organizzazione.
Seleziona Amministrazione > Ambiente > Magazzini chiavi TLS .
Perimetrale classico (Private Cloud)
Nota: l'interfaccia utente di Edge classica è disponibile solo con Edge per il Private Cloud.
Per accedere alla pagina delle caselle chiavi TLS utilizzando l'interfaccia utente classica di Edge:
Accedi a http://ms-ip :9000
come amministratore dell'organizzazione , dove ms-ip è
Indirizzo IP o nome DNS del nodo del server di gestione.
Seleziona la tua organizzazione.
Seleziona Amministratore > Configurazione dell'ambiente > Archivi chiavi TLS .
Viene visualizzata la pagina Magazzini chiavi TLS:
Come evidenziato nella figura precedente, la pagina Magazzini chiavi TLS ti consente di:
Nota: i passaggi negli argomenti che seguono sono specifici per l'interfaccia utente di Edge. I passaggi per l'interfaccia utente di Edge classica sono simili a quelli descritti.
Visualizzare un alias
Per visualizzare un alias:
Accedi alla pagina degli archivi chiavi TLS .
Seleziona l'ambiente (in genere prod
o test
).
Fai clic sulla riga associata all'alias che vuoi visualizzare.
Vengono visualizzati i dettagli del certificato e della chiave alias.
Puoi visualizzare tutte le informazioni sull'alias, inclusa la data di scadenza.
Gestisci il certificato utilizzando i pulsanti nella parte superiore della pagina per:
Scarica il certificato come file PEM.
Genera una CSR. Se hai un certificato scaduto e vuoi rinnovarlo, puoi scaricare una
richiesta di firma del certificato (CSR). Invierai quindi il CSR alla tua CA per ottenere un nuovo
certificato.
Aggiorna un certificato. Attenzione : se aggiorni un certificato che è
attualmente utilizzato da un host virtuale o da un server/endpoint di destinazione
contatta il supporto Apigee Edge per riavviare i router e i processori di messaggi. Il modo consigliato per aggiornare un
certificato è:
Crea un nuovo keystore o truststore.
Aggiungi il nuovo certificato al nuovo keystore o truststore.
Aggiorna il riferimento nell'host virtuale oppure
server/endpoint di destinazione
un archivio chiavi
o un archivio attendibilità. Per saperne di più, consulta
Aggiornare un certificato TLS per il cloud .
Elimina l'alias. Nota : se elimini un alias attualmente in uso da un host virtuale o da un endpoint di destinazione, l'host virtuale o l'endpoint di destinazione non funzionerà.
Creare un archivio chiavi/un archivio attendibile e un alias
Puoi creare un keystore da utilizzare come keystore TLS o come truststore TLS. Un archivio chiavi
è specifico di un ambiente nella tua organizzazione, ad esempio l'ambiente di test o di produzione.
Pertanto, se vuoi testare l'archivio chiavi in un ambiente di test prima di eseguirne il deployment
di produzione, devi crearlo in entrambi gli ambienti.
Per creare un archivio chiavi in un ambiente, è sufficiente specificare il nome dell'archivio chiavi. Dopo
creare un archivio chiavi denominato in un ambiente, quindi creare alias e caricare una coppia certificato/chiave
(keystore) o carica solo un certificato (truststore) nell'alias.
Per creare un archivio chiavi:
Accedi alla pagina degli archivi chiavi TLS .
Seleziona l'ambiente (in genere prod
o test
).
Fai clic su + Archivio chiavi .
Specifica il nome dell'archivio chiavi. Il nome può contenere solo caratteri alfanumerici.
Fai clic su Aggiungi Keystore . Il nuovo keystore viene visualizzato nell'elenco.
Per aggiungere un alias, utilizza una delle seguenti procedure. Vedi anche
Formati di file di certificati supportati .
Creazione di un alias da un certificato (solo truststore)
Per creare un alias a partire da un certificato:
Accedi alla pagina degli archivi chiavi TLS .
Posiziona il cursore sul keystore per visualizzare il menu di azioni e fai clic su + .
Specifica il Nome alias .
In Dettagli certificato, seleziona Solo certificato nel menu a discesa Tipo.
Fai clic su Scegli file accanto a File di certificato , vai alla
File PEM contenente il certificato e fai clic su Apri .
Per impostazione predefinita, l'API controlla che il certificato non sia scaduto. (Facoltativo) Seleziona
Consenti certificato scaduto per saltare la convalida.
Seleziona Salva per caricare il certificato e creare l'alias.
Creazione di un alias da un file JAR
(solo per l'archivio chiavi)
Per creare un alias da un file JAR:
Accedi alla pagina degli archivi chiavi TLS .
Posiziona il cursore sul keystore per visualizzare il menu di azioni e fai clic su + .
Specifica il nome dell'alias .
In Dettagli del certificato, seleziona File JAR nel menu a discesa Tipo.
Fai clic su Scegli file accanto a File JAR , vai al file JAR contenente il certificato e la chiave e fai clic su Apri .
Se la chiave ha una password, specifica la Password . se la chiave non ha
per la password, lascia vuoto questo campo.
Per impostazione predefinita, l'API controlla che il certificato non sia scaduto. Se vuoi, seleziona Consenti certificato scaduto per saltare la convalida.
Seleziona Salva per caricare la chiave e il certificato e creare l'alias.
Creazione di un alias da un certificato e
una chiave (solo archivio chiavi)
Per creare un alias da un certificato e una chiave:
Accedi alla pagina degli archivi chiavi TLS .
Posiziona il cursore sull'archivio chiavi per visualizzare il menu azione e fai clic su + .
Specifica il nome dell'alias .
In Dettagli certificato, seleziona Certificato e chiave dall'elenco a discesa Tipo.
Fai clic su Scegli file accanto a File di certificato , vai al file PEM contenente il certificato e fai clic su Apri .
Se la chiave ha una password, specifica la Password chiave . Se la chiave non ha password, lascia questo campo vuoto.
Fai clic su Scegli file accanto a File della chiave , vai al file PEM contenente la chiave e fai clic su Apri .
Per impostazione predefinita, l'API controlla che il certificato non sia scaduto. Se vuoi, seleziona
Consenti certificato scaduto per saltare la convalida.
Seleziona Salva per caricare la chiave e il certificato e creare l'alias.
La creazione di un alias da una
File PKCS12/PFX (solo archivio chiavi)
Per creare un alias da un file PKCS12 contenente il certificato e la chiave:
Accedi alla pagina Certificati TLS .
Posiziona il cursore sull'archivio chiavi per visualizzare il menu azione e fai clic su + .
Specifica il Nome alias .
In Dettagli certificato, seleziona PKCS12/PFX nell'elenco a discesa Tipo.
Fai clic su Scegli file accanto a PKCS12/PFX , vai al
file contenente la chiave e il certificato e fai clic su Apri .
Se la chiave ha una password, specifica la Password per il file PKCS12/PFX.
Se la chiave non ha una password, lascia vuoto questo campo.
Per impostazione predefinita, l'API verifica che il certificato non sia scaduto. Se vuoi, seleziona
Consenti certificato scaduto per saltare la convalida.
Seleziona Salva per caricare il file e creare l'alias.
Creazione di un alias da un
certificato autofirmato (solo keystore)
Per creare un alias che utilizza un certificato autofirmato, compila un modulo con le informazioni necessarie
le informazioni necessarie per creare il certificato. Edge crea quindi il certificato e una coppia di chiavi private e li carica nell'alias.
Per creare un alias da un certificato autofirmato:
Accedi alla pagina Certificati TLS .
Posiziona il cursore sull'archivio chiavi per visualizzare il menu azione e fai clic su + .
Specifica il nome dell'alias .
In Dettagli certificato, seleziona Certificato autofirmato nel menu a discesa Tipo.
Compila il modulo utilizzando la tabella seguente.
Seleziona Salva per creare la coppia di certificati e chiavi private e caricarli nell'alias.
Nel certificato generato, vedrai i seguenti campi aggiuntivi:
Emittente
La persona giuridica che ha firmato ed emesso il certificato. Per un certificato autofirmato, si tratta del valore CN specificato al momento della creazione del certificato.
Validità
Il periodo di validità del certificato rappresentato da due date: la data in cui il certificato
inizia il periodo di validità e la data in cui termina il periodo di validità. Entrambe possono essere
codificati come valori UTCTime o GeneralizedTime.
Nella tabella seguente vengono descritti i campi del modulo:
Campo modulo
Descrizione
Predefinito
Obbligatorio
Nome dell'alias
Nome alias. La lunghezza massima è di 128 caratteri.
N/D
Sì
Dimensioni della chiave
Dimensioni della chiave, in bit. Il valore predefinito e massimo è 2048 bit.
2048
No
Algoritmo di firma
Algoritmo di firma per generare la chiave privata. I valori validi sono "SHA512withRSA",
"SHA384withRSA" e "SHA256withRSA" (valore predefinito).
SHA256withRSA
No
Validità del certificato in giorni
Durata di validità del certificato, in giorni. Accetta valori positivi diversi da zero.
365
No
Nome comune
Il nome comune (CN) dell'organizzazione identifica i nomi di dominio completi
associati al certificato. In genere è composto da un host e da un nome di dominio.
Ad esempio, api.enterprise.apigee.com, www.apigee.com e così via. La lunghezza massima è di 64 caratteri.
A seconda del tipo di certificato , il valore CN può essere costituito da uno o più nomi host appartenenti allo stesso dominio (ad es. example.com, www.example.com), da un nome con carattere jolly (ad es. *.example.com) o da un elenco di domini. Non
includere alcun protocollo (http:// o https://), numero di porta o percorso della risorsa.
Il certificato è valido solo se il nome host della richiesta corrisponde ad almeno uno dei nomi comuni del certificato.
N/D
Sì
Email
Indirizzo email. La lunghezza massima è di 255 caratteri.
N/D
No
Nome unità organizzativa
Nome del team dell'organizzazione. La lunghezza massima è di 64 caratteri.
N/D
No
Nome organizzazione
Nome dell'organizzazione. La lunghezza massima è di 64 caratteri.
N/D
No
Località
Nome della città. La lunghezza massima è di 128 caratteri.
N/D
No
Provincia
Nome dello stato/della provincia. La lunghezza massima è di 128 caratteri.
N/D
No
Paese
Codice paese di due lettere. Esempio, IN per l'India, US per gli Stati Uniti d'America.
N/D
No
Nomi alternativi
Elenco di nomi host alternativi. Consente di associare identità aggiuntive all'oggetto
del certificato. Le opzioni definite includono un indirizzo di posta elettronica Internet, un DNS
un nome, un indirizzo IP e un URI (Uniform Resource Identifier).
Massimo 255 caratteri per ogni valore. Puoi separare i nomi con una virgola o premendo il tasto Invio dopo ogni nome.
N/D
No
Testa un archivio chiavi o un archivio attendibili
Puoi testare il truststore e il keystore nell'interfaccia utente di Edge per verificare che siano configurati correttamente. L'interfaccia utente di Test convalida una richiesta TLS da Edge a un servizio di backend. Il servizio di backend può essere configurato per supportare TLS unidirezionale o bidirezionale.
Per testare il protocollo TLS unidirezionale:
Accedi alla pagina degli archivi chiavi TLS .
Seleziona l'ambiente (in genere prod
o test
).
Posiziona il cursore sull'archivio chiavi TLS che vuoi testare per visualizzare il menu delle azioni e fai clic su Test . Viene visualizzata la seguente finestra di dialogo che mostra il nome del truststore:
Inserisci il nome host del servizio di backend.
Inserisci il numero di porta TLS (in genere 443).
Facoltativamente, puoi specificare eventuali protocolli o crittografie.
Seleziona Testa .
Per testare TLS bidirezionale:
Per il truststore che ti interessa, seleziona il pulsante Test .
Nella finestra di dialogo, seleziona Bidirezionale per il Tipo di test SSL .
Viene visualizzata la seguente finestra di dialogo:
Specifica il nome del keystore utilizzato in TLS bidirezionale.
Specifica il nome dell'alias nell'archivio chiavi contenente il certificato e la chiave.
Inserisci il nome host del servizio di backend.
Inserisci il numero di porta TLS (in genere 443).
Facoltativamente, puoi specificare eventuali protocolli o crittografie.
Seleziona Testa .
Aggiungere un certificato a un truststore per TLS bidirezionale
Quando utilizzi TLS a due vie per le connessioni in entrata , ovvero una richiesta API in Edge,
l'archivio attendibilità contiene un certificato o una catena CA per ogni client autorizzato a effettuare richieste a Edge.
Quando configuri inizialmente il truststore, puoi aggiungere tutti i certificati per i client noti.
Tuttavia, nel tempo, potresti voler aggiungere altri certificati al truststore man mano che aggiungi nuovi client.
Per aggiungere nuovi certificati a un truststore utilizzato per TLS bidirezionale:
Assicurati di utilizzare un riferimento al truststore nell'host virtuale.
Carica un nuovo certificato nel truststore come descritto sopra in
Creare un alias da un certificato (solo truststore) .
Aggiorna il riferimento dell'archivio attendibilità in modo che venga impostato sullo stesso valore.
Con questo aggiornamento, Edge ricarica l'archivio attendibilità e il nuovo certificato.
Per saperne di più, consulta Modificare un riferimento .
Elimina un archivio chiavi/un archivio attendibilità o un alias
Presta attenzione quando elimini un archivio chiavi/truststore o un alias. Se elimini un keystore, un truststore o un alias utilizzato da un host virtuale, un endpoint target o un server target, tutte le chiamate API tramite l'host virtuale o l'endpoint/il server target non andranno a buon fine.
In genere, la procedura utilizzata per eliminare un archivio chiavi/truststore o un alias è la seguente:
Crea un nuovo archivio chiavi/truststore o alias come descritto sopra.
Per le connessioni in entrata , ovvero una richiesta API in Edge, aggiorna
configurazione dell'host virtuale per fare riferimento al nuovo archivio chiavi e all'alias della chiave.
Per le connessioni in uscita , ossia da Apigee a un server di backend:
Aggiorna la configurazione di TargetEndpoint per tutti i proxy API che facevano riferimento al vecchio
keystore e all'alias chiave in modo che facciano riferimento al nuovo keystore e all'alias chiave. Se TargetEndpoint
fa riferimento a un TargetServer, aggiorna la definizione di TargetServer in modo che faccia riferimento al nuovo keystore
e all'alias chiave.
Se viene fatto riferimento all'archivio chiavi e all'archivio chiavi direttamente dal punto di destinazione
devi eseguire nuovamente il deployment del proxy. Se TargetEndpoint fa riferimento a una definizione di TargetServer e la definizione di TargetServer fa riferimento al keystore e al truststore, non è necessario il ricollocamento del proxy.
Verifica che i proxy API funzionino correttamente.
Elimina l'archivio chiavi/truststore o l'alias.
Elimina un archivio chiavi
Puoi eliminare un archivio chiavi o un archivio attendibilità posizionando il cursore sull'archivio chiavi o sull'archivio chiavi nell'elenco per visualizzare le azioni
menu e facendo clic su . Se elimini un keystore o un truststore utilizzato da un host virtuale o da un endpoint/server di destinazione, tutte le chiamate API tramite l'host virtuale o l'endpoint/server di destinazione non andranno a buon fine.
Attenzione : non devi eliminare un keystore finché non hai convertito gli host virtuali e gli endpoint/i server di destinazione in modo che utilizzino un nuovo keystore.
Eliminare un alias
Puoi eliminare un alias posizionando il cursore del mouse sull'alias nell'elenco per visualizzare il menu delle azioni e facendo clic su . Se elimini un alias utilizzato da un host virtuale o da un endpoint/server di destinazione, tutte le chiamate API tramite l'host virtuale o l'endpoint/server di destinazione non andranno a buon fine.
Attenzione : non eliminare un alias finché non hai convertito il file
ed endpoint/server di destinazione di utilizzare un nuovo archivio chiavi e un nuovo alias.