bg-tutorials

Come generare un codice CSR sui server Oracle

Questa guida ti mostra come generare una CSR (Certificate Signing Request) sui server Oracle. Copre i tre prodotti Oracle in cui creeresti una CSR localmente: Oracle Wallet Manager (o il moderno comando orapki), Oracle iPlanet Web Server e Oracle WebLogic Server (Java keytool). Scegli la sezione che corrisponde al tuo prodotto, segui i passaggi, quindi invia la CSR alla tua Certificate Authority.

Genera una CSR su Oracle Wallet Manager

Se hai già generato la tua CSR, passa direttamente a come installare il certificato SSL su Oracle. Altrimenti, hai due opzioni su Oracle Wallet Manager: l’interfaccia grafica di Oracle Wallet Manager (OWM) oppure la moderna utility a riga di comando orapki inclusa nei prodotti Oracle. Il percorso orapki è scriptabile ed è l’opzione consigliata da Oracle per le distribuzioni attuali; OWM rimane comunque supportato per le stesse operazioni.

Opzione A: Oracle Wallet Manager (GUI)

  1. Apri Oracle Wallet Manager. Se non hai ancora un wallet, scegli Wallet > New, imposta una password sicura e salvalo.
  2. Dal menu principale, scegli Operations > Add Certificate Request.
  3. Nella finestra di dialogo, compila i dettagli della richiesta di certificato esattamente come la tua organizzazione è legalmente registrata:
    • Common Name (CN): il nome di dominio completo (FQDN) che vuoi proteggere, ad esempio www.tuodominio.com, oppure un wildcard come *.tuodominio.com. Non inserire il nome di una persona.
    • Organizational Unit (OU): le CA pubbliche non emettono più questo campo. Lascialo vuoto.
    • Organization (O): la ragione sociale completa della tua azienda, ad esempio Tua Azienda SRL. Per i certificati DV (Domain Validation), puoi lasciarlo vuoto.
    • Locality / City (L): il nome completo della città in cui è registrata la tua azienda, ad esempio Milano. Non abbreviare.
    • State / Province (ST): il nome completo della regione o provincia, ad esempio Lombardia. Non usare un codice di due lettere.
    • Country (C): il codice paese ISO di due lettere, ad esempio US, GB, DE.
    • Key Size: 2048 bit è l’attuale minimo pubblico. I wallet Oracle offrono 512, 1024, 2048, 4096 e dimensioni superiori, senza opzione 3072, quindi il passo successivo qui è 4096.
  4. Clicca su OK. Una finestra di conferma segnala l’avvenuta generazione della CSR. Il nodo del certificato nel menu di navigazione del wallet mostra ora lo stato Certificate: [Requested].
  5. Nella vista del wallet, scegli Operations > Export Certificate Request, assegna un nome al file (ad esempio tuodominio.csr) e salvalo. Non chiudere né eliminare il wallet: ora contiene la chiave privata associata a questa CSR.

Nota: l’interfaccia grafica di Oracle Wallet Manager non espone un campo separato per il Subject Alternative Name (SAN). I browser moderni e i client TLS validano i certificati in base all’estensione SAN, non al Common Name, quindi elenca ogni hostname di cui hai bisogno (ad esempio tuodominio.com e www.tuodominio.com) nel campo SAN del modulo d’ordine della tua Certificate Authority. La CA li aggiungerà al certificato emesso. Se usi la riga di comando orapki (Opzione B qui sotto), puoi incorporare i SAN direttamente nella CSR con il flag -addext_san.

Opzione B: orapki (riga di comando)

L’utility orapki è inclusa nei prodotti Oracle (nelle distribuzioni del database, Fusion Middleware e HTTP Server) ed è l’alternativa scriptabile a OWM. Il flusso prevede due comandi: creare il wallet e la coppia di chiavi, quindi esportare la CSR.

Crea un wallet con auto-login e aggiungi una coppia di chiavi:

orapki wallet create -wallet /etc/oracle/wallet -auto_login -pwd "YourStrongPassword"

orapki wallet add -wallet /etc/oracle/wallet 
  -dn "CN=www.yourdomain.com, O=Your Company LLC, L=Seattle, ST=Washington, C=US" 
  -keysize 2048 
  -addext_san "DNS:yourdomain.com,DNS:www.yourdomain.com" 
  -pwd "YourStrongPassword"

Poi esporta la CSR dal wallet:

orapki wallet export -wallet /etc/oracle/wallet 
  -dn "CN=www.yourdomain.com, O=Your Company LLC, L=Seattle, ST=Washington, C=US" 
  -request /tmp/yourdomain.csr 
  -pwd "YourStrongPassword"

Sostituisci il percorso del wallet, il DN e la password con i tuoi valori. Il DN nel comando export deve corrispondere al DN usato quando hai aggiunto la coppia di chiavi. Il flag -addext_san (orapki 12.2.1.1 e successivi) incorpora i Subject Alternative Name direttamente nella CSR; elenca ogni hostname che il certificato deve coprire, incluso sia il dominio apex sia il sottodominio www. Il file tuodominio.csr ora contiene la CSR, pronta per essere inviata.

Invia la CSR

Apri il file .csr in un qualsiasi editor di testo (ad esempio, Blocco note). Il file è testo semplice, inizia con -----BEGIN NEW CERTIFICATE REQUEST----- (oppure -----BEGIN CERTIFICATE REQUEST-----) e termina con la corrispondente riga -----END. Copia l’intero blocco, comprese quelle righe di intestazione e chiusura, e incollalo nel campo CSR durante il checkout con la tua CA.

Genera una CSR su Oracle iPlanet Web Server

Oracle iPlanet (in precedenza Sun Java System Web Server, poi Sun ONE) conserva i certificati server e le relative chiavi in un token store. La procedura guidata per la CSR si trova nella console di amministrazione:

  1. Nella console di amministrazione di Oracle iPlanet, apri Server Certificates e clicca su Request.
  2. Dall’elenco Configuration, scegli la configurazione a cui è destinato il certificato.
  3. Seleziona il Token (Cryptographic Device) che conterrà la chiave. Se la chiave è memorizzata sul server, scegli Internal; altrimenti seleziona il tuo token esterno dal menu a discesa. Inserisci la password per il token selezionato.
  4. Compila i dettagli del certificato:
    • Server Name: il nome di dominio completo (FQDN) che vuoi proteggere, ad esempio www.tuodominio.com. Per un certificato wildcard, aggiungi un asterisco come prefisso, ad esempio *.tuodominio.com.
    • Organization (O): la ragione sociale completa della tua azienda, ad esempio Tua Azienda SRL.
    • Organizational Unit (OU): deprecato dalle CA pubbliche. Lascialo vuoto.
    • Locality (L): il nome completo della città in cui è registrata la tua organizzazione.
    • State or Province (ST): il nome completo della regione o provincia in cui è registrata la tua organizzazione.
    • Country (C): il codice paese ISO di due lettere, ad esempio US per gli Stati Uniti. Consulta l’elenco completo dei codici paese.
  5. Per Key Type, seleziona RSA con 2048 bit (o superiore).
  6. Per la Certificate Signing Authority (CSA), seleziona CA Signed.
  7. Verifica i valori inseriti, quindi clicca su Generate Request, poi su Finish.
  8. Copia la CSR appena generata (comprese le righe -----BEGIN NEW CERTIFICATE REQUEST----- e -----END NEW CERTIFICATE REQUEST-----) in un file di testo, quindi clicca su Close.

Nota: come Oracle Wallet Manager, la procedura guidata CSR di iPlanet non espone un campo SAN. Fornisci ogni hostname che il certificato deve coprire (apex più www, oltre a qualsiasi altro sottodominio) nel campo SAN del modulo d’ordine della tua CA.

Genera una CSR su Oracle WebLogic Server

Oracle WebLogic Server utilizza i keystore Java. Generi la CSR con l’utility Java keytool in due comandi: prima keytool -genkeypair crea il keystore e la chiave privata sotto un alias scelto, poi keytool -certreq esporta la CSR corrispondente. Lo stesso alias deve essere riutilizzato in seguito quando importi il certificato firmato, in modo che la chiave, la CSR e il certificato finale risiedano tutti nello stesso posto.

Passo 1: Crea il keystore e la chiave privata

Apri un terminale sul server WebLogic e crea un nuovo keystore in formato PKCS12. PKCS12 è il formato di keystore predefinito in Java dalla JDK 9 ed è lo standard moderno e portabile. Il formato proprietario più datato JKS è ufficialmente deprecato:

keytool -genkeypair 
  -alias server 
  -keyalg RSA -keysize 2048 
  -storetype PKCS12 
  -keystore yourdomain.p12 
  -validity 825

Significato dei flag:

  • -alias server: il nome della voce all’interno del keystore. Scegli un’etichetta che riconoscerai (spesso server, o il tuo dominio). Annotala. Devi riutilizzare esattamente questo alias quando generi la CSR e di nuovo quando importi il certificato firmato.
  • -keyalg RSA -keysize 2048: una chiave RSA a 2048 bit è l’attuale minimo pubblico. Per i nuovi keystore, 3072 bit è un aggiornamento ragionevole per chiavi con vita più lunga. La maggior parte delle CA pubbliche accetta anche ECDSA (-keyalg EC -groupname secp256r1) se preferisci una chiave più piccola e veloce; -groupname richiede JDK 13 o successive, quindi sui runtime Java 8 e Java 11 supportati dalle versioni più datate di WebLogic, usa invece -keyalg EC -keysize 256, che seleziona la stessa curva.
  • -storetype PKCS12: forza il moderno keystore PKCS12. L’estensione corrispondente è .p12 (o .pfx).
  • -keystore yourdomain.p12: il file keystore da creare. Sostituiscilo con qualcosa che ricorderai, e conserva il file in modo sicuro: contiene la tua chiave privata.
  • -validity 825: per quanto tempo è valido il certificato segnaposto autofirmato all’interno del keystore. Il certificato firmato dalla CA lo sostituirà in seguito, quindi il valore esatto non influisce sulla durata in produzione.

Nota: se devi continuare a usare JKS per una distribuzione WebLogic più datata, sostituisci -storetype PKCS12 con -storetype JKS e usa un’estensione .jks. Il resto del flusso di lavoro è identico. Per i certificati wildcard, non usare un asterisco nel nome del file keystore: quel carattere non è supportato dalla maggior parte dei filesystem.

keytool chiede quindi una password del keystore. Scegli una password sicura e conservala nel tuo gestore di segreti: ne avrai bisogno per ogni successivo comando keytool e per la configurazione del keystore di WebLogic. Con i keystore PKCS12, la password della chiave coincide con la password del keystore, quindi c’è una sola password da ricordare.

Passo 2: Inserisci i dettagli della tua organizzazione (DN)

keytool ora chiede il Distinguished Name (DN): i campi identificativi che vanno nella CSR. Rispondi a ogni richiesta con il valore esatto e legale della tua organizzazione. Punteggiatura e precisione contano, poiché una CA rifiuterà eventuali discrepanze rispetto ai registri commerciali pubblici.

  • First and last name (CN): questa è la dicitura di keytool, ma corrisponde al campo Common Name. Inserisci l’esatto FQDN che stai proteggendo, ad esempio www.tuodominio.com, oppure un wildcard come *.tuodominio.com. Non inserire il nome di una persona.
  • Organizational unit (OU): non più emesso dalle CA pubbliche. Non provare a saltarlo premendo Invio: keytool sostituisce il proprio valore predefinito e scrive OU=Unknown nella richiesta, e rispondere con uno spazio produce lo stesso risultato. Non esiste un modo interattivo per ometterlo, quindi digita il nome del dipartimento, ad esempio IT, oppure usa la forma -dname mostrata di seguito e ometti la componente OU dalla stringa.
  • Organization (O): la ragione sociale completa della tua azienda, ad esempio Tua Azienda SRL. Se il nome della tua azienda contiene simboli come & o @, scrivili per esteso o omettili; keytool rifiuterà alcuni caratteri speciali.
  • City or locality (L): il nome completo della città, ad esempio Milano. Non abbreviare.
  • State or province (ST): il nome completo della regione o provincia, ad esempio Lombardia. Non usare un codice di due lettere.
  • Country code (C): il codice paese ISO di due lettere, ad esempio US, GB, DE.

Dopo l’ultima richiesta, keytool mostra un riepilogo simile a CN=www.tuodominio.com, OU=Unknown, O=Tua Azienda SRL, L=Milano, ST=Lombardia, C=IT. Digita yes per confermare. Il file keystore ora esiste con una voce: il tuo alias, che contiene la chiave privata e un certificato segnaposto autofirmato.

Se preferisci un comando non interattivo, passa il DN in linea e salta le richieste:

keytool -genkeypair 
  -alias server 
  -keyalg RSA -keysize 2048 
  -storetype PKCS12 
  -keystore yourdomain.p12 
  -dname "CN=www.yourdomain.com, O=Your Company LLC, L=San Francisco, ST=California, C=US" 
  -validity 825

Passo 3: Genera la CSR con SAN

I browser moderni e i client TLS validano i certificati in base all’estensione Subject Alternative Name (SAN), non solo in base al Common Name. Richiedi i SAN direttamente nella CSR in modo che la CA li includa nel certificato emesso. Usa lo stesso alias e keystore del Passo 1:

keytool -certreq 
  -alias server 
  -keystore yourdomain.p12 
  -file yourdomain.csr 
  -ext san=dns:yourdomain.com,dns:www.yourdomain.com

Significato dei flag:

  • -alias server: deve corrispondere all’alias del Passo 1. È l’alias la cui chiave privata firma la richiesta.
  • -keystore yourdomain.p12: deve corrispondere al keystore del Passo 1.
  • -file yourdomain.csr: il nome del file di output per la CSR.
  • -ext san=dns:…: l’estensione Subject Alternative Name. Elenca ogni hostname che il certificato deve coprire, incluso sia l’apex nudo (tuodominio.com) sia il sottodominio www. Aggiungi altre voci separate da virgola, ad esempio dns:api.tuodominio.com.

keytool chiede la password del keystore e scrive la CSR in yourdomain.csr nella directory corrente.

Fondamentale: conserva il tuo alias e keystore

L’errore più comune con keytool su WebLogic è importare il certificato firmato sotto un nuovo alias. Facendo così, il certificato viene memorizzato come voce attendibile a sé stante, senza chiave privata associata, e il listener SSL di WebLogic non si avvierà. Importa sempre la risposta firmata nello stesso alias che contiene la chiave privata (l’alias del Passo 1).

Annota questi tre valori ora, prima di chiudere il terminale:

  • L’alias (in questa guida, server).
  • Il percorso del file keystore (ad esempio yourdomain.p12).
  • La password del keystore.

Se non sei sicuro di quale alias contenga la tua chiave, elenca il contenuto del keystore e cerca la voce il cui tipo è PrivateKeyEntry:

keytool -list -v -keystore yourdomain.p12

Passo 4: Verifica la CSR prima di inviarla

Individua eventuali errori di battitura nel DN o SAN mancanti prima che la CA li convalidi. Stampa la CSR con keytool:

keytool -printcertreq -file yourdomain.csr

Oppure, se OpenSSL è installato:

openssl req -noout -text -in yourdomain.csr

Verifica tre cose nell’output: il Subject mostra il tuo DN esatto, il Subject Alternative Name elenca ogni hostname di cui hai bisogno, e la dimensione della Public-Key corrisponde a quella richiesta (RSA a 2048 bit, o qualsiasi altra tu abbia scelto). Puoi anche incollare la CSR nel nostro CSR Decoder per lo stesso controllo in un browser.

Passo 5: Invia la CSR alla tua Certificate Authority

Apri yourdomain.csr in un qualsiasi editor di testo. Il file è testo semplice, inizia con -----BEGIN NEW CERTIFICATE REQUEST----- e termina con -----END NEW CERTIFICATE REQUEST-----. Copia l’intero blocco, comprese quelle righe di intestazione e chiusura, e incollalo nel campo CSR durante il checkout con la tua CA. Su Windows, usa Ctrl + A poi Ctrl + C per catturare l’intero testo; su macOS, usa Cmd + A poi Cmd + C.

Esegui il backup del file keystore (yourdomain.p12) in un luogo sicuro prima di chiudere il terminale. Se perdi il keystore, perdi la chiave privata, e il certificato emesso dalla CA sarà inutilizzabile.

Dopo che la CA ha convalidato la tua richiesta ed emesso il certificato, prosegui con come installare il certificato SSL su Oracle. Su WebLogic, importi il certificato firmato nello stesso alias nello stesso keystore, e poi indirizzi il listener SSL a quel keystore.

Risparmia il 10% sui certificati SSL ordinando oggi stesso da SSL Dragon!

Emissione rapida, crittografia avanzata, affidabilità del browser al 99,99%, assistenza dedicata e garanzia di rimborso entro 25 giorni. Codice coupon: SAVE10

Un'immagine dettagliata di un drago in volo
Scritto da

Scrittore di contenuti con esperienza, specializzato in certificati SSL. Trasforma intricati argomenti di cybersicurezza in contenuti chiari e coinvolgenti. Contribuisci a migliorare la sicurezza digitale attraverso narrazioni d'impatto.

Avatar of Sergiu Rosca
Technical Review by Sergiu Rosca

Sergiu Rosca is the core web developer behind SSL Dragon. He manages the technical infrastructure, platform performance, and backend integrations that keep the site running smoothly and securely. At SSL Dragon, Sergiu shares practical insights on web development, site optimization, and technical troubleshooting.

All SSL Dragon installation guides are tested on live server environments and undergo a strict peer-review process to ensure your infrastructure remains secure. Read our full Editorial Policy.