In questa seconda parte volevo procedere con la generazione di un certificato da utilizzare con il nostro Secure Gateway.
La gestione dei certificati risulta spesso ostica perché si finisce sempre per utilizzare strumenti poco intuitivi e a parlare di formati di certificati strani che confondono solo le idee a chi non è già molto pratico. In realtà l’esperienza sul campo mi ha portato a suggerire sempre di utilizzare gli strumenti di gestione dell’Internet Information Server per gestire i certificati SSL per il Secure Gateway. Questo significa installare IIS sul server dove risiede il nostro Secure Gateway; spesso Web Interface e Secure Gateway risiedono sulla stessa macchina, ma se così non fosse, l’installazione di un IIS inutilizzato non dovrebbe causare problemi.
Utilizziamo IIS per la gestione del certificato, ma in realtà ci interessa lasciare la porta 443 (quella del servizio HTTPS) libera per Citrix Secure Gateway. Dovremo quindi configurare IIS per usare il certificato su una porta diversa, per esempio la 444.
Andando sulle proprietà del sito di default (o di quello su cui abbiamo installato la Web Interface) possiamo iniziare la procedura guidata di creazione di un certificato SSL selezionando il pulsate “Server Certificate” sotto la scheda “Dirctory Security”:
Il primo passo è creare un nuovo certificato:
Se il nostro server è inserito in dominio e su Ative Directory è registrata una Certification Authority, possiamo inviare direttamente la richiesta. Spesso il nostro Secure Gateway è inserito in una DMZ e potrebbe anche non essere in dominio: per questo motivo in questo articolo prendiamo in considerazione la via più lunga….
Scegliamo quindi di preparare la richiesta, ma di non inviarla automaticamente (se non siamo in AD, la seconda opzione è in grigio e non è selezionabile). A questo punto ci vengono richieste le informazioni necessarie alla creazione del nostro certificato.
I primi due parametri da inserire sono il nome de certificato e la sua lunghezza:
Il nome che inseriamo qui è mnemonico e ci serve per sapere che certificato stiamo creando: non è da confondere con il Common Name, che deve corrispondere al FQDN, che ci verrà richiesto più avanti.
Dobbiamo poi inserire il nome della nostra società e dell’ufficio richiedente:
Questi valori saranno poi consultabili guardando le proprietà del certificato, quindi è meglio evitare di scrivere valori troppo di fantasia (un certificato richiesto dall’ufficio “pluto” dell’azienda “pippo” potrebbe non essere molto credibile).
Subito dopo ci viene richiesto di inserire il Common Name a cui il certificato fa riverimento:
Questa è una delle informazioni più importanti del certificato: è il nome con cui viene chiamato il sito, il fully qualified domain name (FQDN)! Se questo nome non corrisponde al nome internet del nostro Secure Gateway, il certificato non è valido (fallisce uno dei tre test) e il Client ICA non è in grado di stabilire la connessione.
Infine dobbiamo inserire le informazioni geografiche relative alla nostra azienda:
Anche queste informazioni saranno visibili all’interno del certificato. A questo punto inseriamo il path in cui salvare la richiesta (di default viene salvata sulla radice del disco di sistema) e siamo arrivati alla fine della prima fase di creazione del certificato.
Next e Finish….
Adesso dobbiamo inoltrare la nostra richiesta alla Certification Authority. Di default la CA Microsoft installa alcune pagine web che ci permettono di fare la richiesta del certificato tramite un browser web. Se il server che stiamo usando non è in grado di connettersi via web alla CA, è necessario copiare il file certreq.txt che abbiamo appena creato su un PC in LAN.
Apriamo il browser e andiamo all’indirizzo http://<CA-Server>/certsrv/; nel mio caso il server si chiama DemoDC
Ovviamente dobbiamo richiedere un certificato….
Di dfault ci verrà proposta la richiesta di un certificato utente, ma a noi server un certificato per il nostro server…. Dobbiamo quindi fare una richiesta avanzata.
Apriamo il file certreq.txt che abbiamo creato poco fa (con un doppio click, il file viene aperto nel Blocco Note): il suo contenuto è del testo, per noi illeggibile: in realtà è in formato base64. Selezioniamo quindi la seconda opzione (Submit a certificate request by using a base-64-encoded CMC or PKCS#10 file…)
Selezioniamo il testo dal Blocco Note e inseriamolo nel modulo di richiesta.
Dobbiamo solo verificare il Template del certificato: il nostro certificato serve per un Web Server! Dobbiamo quindi selezionare il Certificate Template e impostarlo sul valore corretto.
Il nostro certificato è stato rilasciato. In realtà se stiamo usando un utente che non ha i diritti per rilasciare i certificati sulla nostra Certification Authority, è necessario che un utente amministratore si colleghi sul server in questione e, tramite lo snap-in di gestione della Certification Autority, autorizzi il rilascio del nostro certificato; fatto questo dovremo ritornare sulla pagina web della CA e scaricare il certificato (Download CA Certificate….). Ora selezioniamo il formato e scarichiamo il certificato. Se scarichiamo la “certificate chain”, siamo semplicemente scaricando anche il certificato pubblico della (o delle) CA che hanno firmato il nostro certificato. Con il nostro file certnew.cer possiamo ora ritornare sul nostro IIS e processare la richiesta di prima: torniamo nella scheda “Directory Security” del nostro sito e selezioniamo “Server Certificate”.
Selezioniamo il nostro file certnew.cer che abbiamo scaricato dal sito web della nostra Certification Authority:
Dobbiamo ora specificare la porta da usare per il traffico SSL. Comq anticipato all’inizio, non ci interessa che IIS usi il certificato direttamente, anzi abbiamo bisogno che la porta 443 sia libera per il Secure Gateway. Selezioniamo quindi una porta diversa, non in uso da altri servizi, come la porta 444.
Abbiamo completato la creazione del nostro certificato che ora è pronto all’uso. L’ultima finestra ci riporta le specifiche del certificato (che dovrebbero essere identiche a quelle del sommario visualizzato nella prima fase):
Leggi anche Approfondimenti: i certificati SSL e il Secure Gateway (prima parte)