Differenze tra le versioni di "GARRCS:GARR-TCS-4"
(178 versioni intermedie di 4 utenti non mostrate) | |||
Riga 1: | Riga 1: | ||
==GARR Certification Service== | ==GARR Certification Service== | ||
− | GARR CS (Certification Service) gestisce il servizio | + | GARR CS (Certification Service) gestisce il servizio GÉANT TCS (Trusted Certificate Service) per la comunità della ricerca italiana. |
===Adesione=== | ===Adesione=== | ||
− | Per la procedura di adesione | + | Per la procedura di adesione scaricare il file zip contenente moduli e istruzioni da [https://www.garr.it/it/chi-siamo/documenti/servizi/documenti-cs/6730-garr-tcs-4-v3 GARR CS Adesione] |
+ | |||
+ | <u>Prima della compilazione dei moduli di adesione</u> siete pregati di considerare che è necessario indicare il "'''full legal name'''" del vostro Ente affinché Sectigo possa procedere con la '''validazione della Organizzazione''' secondo le regole specificate qui di seguito. | ||
+ | |||
+ | ===Validazione dell'Organizzazione=== | ||
+ | Per poter emettere certificati (SSL, client, code signing) un'Organizzazione deve essere stata validata dalla CA. | ||
+ | |||
+ | Il processo di '''validazione di un'Organizzazione''', svolto dalla CA, avviene inizialmente nel momento dell'adesione e successivamente con '''cadenza annuale'''. Dal 1 settembre 2023 le regole di validazione dell'Organizzazione (OV) sono cambiate per adeguarsi alle <u>Baseline Requirements per l'emissione dei certificati S/MIME</u> e sono diventate molto più complesse rispetto al passato. Le regole, stabilite dal CA/B Forum, sono disponbiili in questo documento: https://cabforum.org/wp-content/uploads/CA-Browser-Forum-SMIMEBR-1.0.0.pdf | ||
+ | |||
+ | Sectigo ha diffuso un video webinar di approfondimento sulle nuove Baseline Requirements per S/MIME: <nowiki>https://www.youtube.com/watch?v=ewsbwSDOd6k</nowiki> | ||
+ | |||
+ | Il punto fondamentale delle nuove regole è: '''"3.2.3.2.1 <u>Verification of name, address, and unique identifier</u>"''' e riguarda la documentazione da presentare per provare alla CA l''''<u>esistenza legale</u>''' della propria Organizzazione: | ||
+ | |||
+ | #A government agency in the jurisdiction of the Legal Entity’s creation, existence, or recognition; | ||
+ | #A Legal Entity Identifier (LEI) data reference; | ||
+ | #A site visit by the CA or a third party who is acting as an agent for the CA; or | ||
+ | #An Attestation which includes a copy of supporting documentation used to establish the Applicant’s legal existence, such as a certificate of registration, articles of incorporation, operating agreement, statute, or regulatory act. | ||
+ | |||
+ | Per esperienza recente, abbiamo visto che vengono accettati i seguenti link a siti web e documenti: | ||
+ | |||
+ | *Indicepa: banca dati di libera consultazione (<nowiki>https://indicepa.gov.it/ipa-portale/</nowiki>) | ||
+ | *Registro Imprese (https://www.registroimprese.it/) e visure camerali | ||
+ | *VIES VAT number validation (https://ec.europa.eu/taxation_customs/vies/#/vat-validation) | ||
+ | *Durc online (https://www.inail.it/cs/internet/attivita/assicurazione/verificare-la-regolarita-contributiva-durc-online.html) | ||
+ | *essere indicizzati in un sito governativo italiano o europeo (Ministero, Camera, Senato, Esteri) | ||
+ | *Statuto dell'Organizzazione | ||
+ | *Riferimenti esatti del "full legal name" e indirizzo postale presenti in Gazzetta Ufficiale | ||
+ | *Legal Entity Identifier (LEI) (https://www.gleif.org/en/about-lei/introducing-the-legal-entity-identifier-lei) | ||
+ | |||
+ | Per esperienza, quando la CA non riesce a verificare l'esistenza legale di un'Organizzazione ci contatta chiedendo quanto segue: | ||
+ | |||
+ | '''Oggetto: Legal existence pending''' | ||
+ | |||
+ | <code>As per the revised validation policy we are required to verify the legal existence of all organizations prior to issuing certificates. We are in the process of validating the details of your organization as part of our certificate issuance process. However, we are unable to locate your organization's registration details in our existing records. Kindly provide an official government URL to confirm your organization formation or Act that confirms your organization's legal status and registration information. Once we have verified the information, we will proceed with your order issuance.</code> | ||
+ | |||
+ | Il servizio GARR CS contatterà l'Organizzazione non ancora validata per richiedere la '''prova di esistenza legale''' secondo una delle modalità indicate sopra. La mancata collaborazione nel procurare la documentazione necessaria alla validazione comporterà la mancata emissione dei certificati. | ||
+ | |||
+ | I tempi necessari alla validazione sono molto incerti e dipendono dalla CA: si può andare da un minimo di 2 gg fino a 4 settimane. | ||
+ | |||
+ | La velocità di validazione dipende molto dalla qualità dei documenti e riferimenti presentati. Documenti che non rispettano i requisiti o che sono molto vecchi potrebbero essere rifiutati dalla CA. | ||
===Supporto=== | ===Supporto=== | ||
Riga 21: | Riga 60: | ||
====Link utili==== | ====Link utili==== | ||
− | *Per '''''scaricare | + | *Per '''''scaricare''''' '''''le root intermediate di GÉANT''''' (in uso dal 1 settembre 2023) è disponibile il seguente repository: https://wiki.geant.org/display/TCSNT/TCS+Trust+Anchors+and+Intermediates |
− | *Per conoscere i metodi di '''''validazione DCV alternativi''''' è disponile il seguente articolo di Sectigo: https:// | + | *Per '''''scaricare le root intermediate di GÉANT''''' (in uso fino al 1 settembre 2023) è disponibile il seguente repository: https://crt.sh/?CAName=%25GEANT+Vereniging%25 |
− | *Come '''''generare una richiesta''''' CSR con OpenSSL: https:// | + | |
+ | *Per conoscere i metodi di '''''validazione DCV alternativi''''' è disponile il seguente articolo di Sectigo: https://www.sectigo.com/resource-library/domain-control-validation-dcv-methods-how-to-choose | ||
+ | *Come '''''generare una richiesta''''' CSR con OpenSSL: https://www.sectigo.com/knowledge-base/detail/CSR-Generation-Using-OpenSSL-Apache-w-mod-ssl-NGINX-OS-X/kA01N000000zGKQ | ||
*Come '''''generare una richiesta''''' CSR con OpenSSL per IIS (in formato .pdf by RAO@UNITO): [[Media:CertificatiWindowsIIS.pdf|File:CertificatiWindowsIIS.pdf]] | *Come '''''generare una richiesta''''' CSR con OpenSSL per IIS (in formato .pdf by RAO@UNITO): [[Media:CertificatiWindowsIIS.pdf|File:CertificatiWindowsIIS.pdf]] | ||
*Come '''''generare una richiesta''''' CSR con MMC (Microsoft): https://www.entrustdatacard.com/knowledgebase/ssl/how-to-generate-certificate-signing-request-using-microsoft-management-console-mmc-on-windows-2012 | *Come '''''generare una richiesta''''' CSR con MMC (Microsoft): https://www.entrustdatacard.com/knowledgebase/ssl/how-to-generate-certificate-signing-request-using-microsoft-management-console-mmc-on-windows-2012 | ||
− | *Come '''''generare una richiesta''''' CSR in Windows con certreq (command shell): https:// | + | *Come '''''generare una richiesta''''' CSR in Windows con certreq (command shell): https://www.sectigo.com/knowledge-base/detail/CSR-Generation-Using-certreq-Windows-1527076090647/kA01N000000zFM0 |
− | + | *Come creare un file '''''PKCS#7''''', (.p7b) a partire dal formato .crt /.cer in Windows: [https://www.sectigo.com/knowledge-base/detail/How-to-create-a-PKCS-7-p7b-formats-from-crt-or-cer-certificates-on-Windows/kA03l00000117Se https://www.sectigo.com/knowledge-base/detail/How-to-create-a-PKCS-7-p7b-formats-from-crt-or-cer-certificates-on-Wind ows/kA03l00000117Se] | |
− | *Come creare un file '''''PKCS#7''''', (.p7b) a partire dal formato .crt /.cer in Windows: https:// | + | *'''Internal domain/server names''' (Reserved IP Addresses): https://www.sectigo.com/knowledge-base/detail/Internal-domain-server-names-Reserved-IP-Addresses-1527076114398/kA01N000000zFUB |
− | *'''Internal domain/server names''' (Reserved IP Addresses): https:// | ||
===Documentazione Sectigo=== | ===Documentazione Sectigo=== | ||
Riga 41: | Riga 81: | ||
*''SCM - Sectigo Certificate Manager REST API'' è la guida per interfacciarsi al sistema con le API REST | *''SCM - Sectigo Certificate Manager REST API'' è la guida per interfacciarsi al sistema con le API REST | ||
− | + | GÉANT Wiki TCS 2020 FAQ: https://wiki.geant.org/display/TCSNT/TCS+2020+FAQ | |
===Configurazione iniziale (Quickstart)=== | ===Configurazione iniziale (Quickstart)=== | ||
Riga 49: | Riga 89: | ||
''SCM'' = <u>Sectigo Certificate Manager</u>, il nome del portale per la gestione dei certificati x.509 | ''SCM'' = <u>Sectigo Certificate Manager</u>, il nome del portale per la gestione dei certificati x.509 | ||
− | ''MRAO'' = <u>Master Registration Authority Officer</u>, ruolo amministrativo di alto livello riservato ad ogni NREN che ha sottoscritto il contratto | + | ''MRAO'' = <u>Master Registration Authority Officer</u>, ruolo amministrativo di alto livello riservato ad ogni NREN che ha sottoscritto il contratto GÉANT TCS. Per GARR il ruolo è affidato ai membri del Servizio GARR CS. |
''RAO'' = <u>Registration Authority Officer</u>, ruolo amministrativo a livello di Organizzazione che permette la gestione di dipartimenti, domini, certificati e ruoli amministrativi afferenti a tale Organizzazione | ''RAO'' = <u>Registration Authority Officer</u>, ruolo amministrativo a livello di Organizzazione che permette la gestione di dipartimenti, domini, certificati e ruoli amministrativi afferenti a tale Organizzazione | ||
Riga 57: | Riga 97: | ||
====Primi passi==== | ====Primi passi==== | ||
− | #E' necessario inizializzare una '''chiave di cifratura''' per ogni Organizzazione e Dipartimento creato nel Portale SCM. Si tratta di una chiave Escrow (https://it.wikipedia.org/wiki/Key_escrow) e senza un'inizializzazione non sarà possibile richiedere certificati personali tramite la GUI del Portale stesso. Per procedere scegliere dal menù principale | + | #E' necessario inizializzare una '''chiave di cifratura''' per ogni Organizzazione e Dipartimento creato nel Portale SCM. Si tratta di una chiave Escrow (https://it.wikipedia.org/wiki/Key_escrow) e senza un'inizializzazione non sarà possibile richiedere certificati personali tramite la GUI del Portale stesso. Per procedere scegliere dal menù principale la voce ''Settings'' e poi ''Legacy Key Encryption''. Selezionare la Organizzazione e premere il bottone [Inizialize Encryption]. Seguire le istruzioni a video e salvare la chiave in maniera sicura per eventuale uso futuro. |
#Per iniziare a richiedere certificati SSL server è necessario creare almeno 1 dominio e validarlo (vedi la sezione "'''Gestione Dominii'''") | #Per iniziare a richiedere certificati SSL server è necessario creare almeno 1 dominio e validarlo (vedi la sezione "'''Gestione Dominii'''") | ||
#Prima di richiedere un certificato EV (Extended Validation) leggere la sezione dedicata più sotto e considerare che la CA deve verificare il numero telefonico aziendale principale e pertanto è necessario che l'ufficio sia presidiato. | #Prima di richiedere un certificato EV (Extended Validation) leggere la sezione dedicata più sotto e considerare che la CA deve verificare il numero telefonico aziendale principale e pertanto è necessario che l'ufficio sia presidiato. | ||
Riga 64: | Riga 104: | ||
Durante il primo mese di utilizzo della nuova piattaforma abbiamo sperimentato alcuni problemi che hanno talvolta impedito l'emissione dei certificati. Ecco un elenco delle più importanti scoperte e soluzioni: | Durante il primo mese di utilizzo della nuova piattaforma abbiamo sperimentato alcuni problemi che hanno talvolta impedito l'emissione dei certificati. Ecco un elenco delle più importanti scoperte e soluzioni: | ||
− | *certificati bloccati in stato '''Applied''': verificare che il CAA record permetta a Sectigo l'emissione dei certificati ([https://www. | + | *certificati bloccati in stato '''Applied''': verificare che il CAA record permetta a Sectigo l'emissione dei certificati ([https://www.nslookup.io/caa-lookup/ on-line check)] |
*errore in fase di approvazione richiesta "'''Please fill all empty required fields of organization/department'''": declinare la richiesta, modificare i privilegi di RAO e DRAO aggiungendo "''SSL auto-approve''" e sottomettere una nuova richiesta. | *errore in fase di approvazione richiesta "'''Please fill all empty required fields of organization/department'''": declinare la richiesta, modificare i privilegi di RAO e DRAO aggiungendo "''SSL auto-approve''" e sottomettere una nuova richiesta. | ||
*errore in fase di richiesta certificato "'''Anchor Certificate address details are different!'''": ricreare una nuova CSR minimale usando il comando openssl <code>openssl req -nodes -newkey rsa:3072 -keyout myserver.key -out server.csr -subj "/C=IT/CN=mysubdomain.mydomain.com"</code>e sottomettere nuovamente | *errore in fase di richiesta certificato "'''Anchor Certificate address details are different!'''": ricreare una nuova CSR minimale usando il comando openssl <code>openssl req -nodes -newkey rsa:3072 -keyout myserver.key -out server.csr -subj "/C=IT/CN=mysubdomain.mydomain.com"</code>e sottomettere nuovamente | ||
− | *Sectigo SCM Error “'''Anchor Certificate details are different'''”: https:// | + | *Sectigo SCM Error “'''Anchor Certificate details are different'''”: https://www.sectigo.com/knowledge-base/detail/Sectigo-Certificate-Manager-SCM-Error-Anchor-Certificate-details-are-different/kA03l000000noiG |
*'''<u>Se dopo aver chiesto nuovamente il certificato con la CSR minimale l'errore persiste contattate GARR CS <garr-ca@garr.it>.</u>''' | *'''<u>Se dopo aver chiesto nuovamente il certificato con la CSR minimale l'errore persiste contattate GARR CS <garr-ca@garr.it>.</u>''' | ||
*dopo aver installato un certificato su un server, '''controllare''' la configurazione della ''certificate chain'': [[GARRCS:GARR-TCS-4#Installazione%20SSL%20Certificate|Paragrafo >> Installazione SSL certificate]] | *dopo aver installato un certificato su un server, '''controllare''' la configurazione della ''certificate chain'': [[GARRCS:GARR-TCS-4#Installazione%20SSL%20Certificate|Paragrafo >> Installazione SSL certificate]] | ||
Riga 75: | Riga 115: | ||
**il modo migliore per accedere a SCM con Idp è creare l'utenza in ''Settings'' > ''Admins'' e nella sezione ''Authentication'' impostare il valore di SAML IDP a "Your Institution" e inserire il valore ePPN dell'utente nell'apposito spazio. | **il modo migliore per accedere a SCM con Idp è creare l'utenza in ''Settings'' > ''Admins'' e nella sezione ''Authentication'' impostare il valore di SAML IDP a "Your Institution" e inserire il valore ePPN dell'utente nell'apposito spazio. | ||
*'''Status''' dei sistemi Sectigo e prossimi aggiornamenti pianificati: https://sectigo.status.io/ | *'''Status''' dei sistemi Sectigo e prossimi aggiornamenti pianificati: https://sectigo.status.io/ | ||
− | |||
− | |||
− | |||
==Registration Authority Officer== | ==Registration Authority Officer== | ||
Riga 97: | Riga 134: | ||
Accedere al sito https://keybase.io/encrypt e completare con i seguenti valori: | Accedere al sito https://keybase.io/encrypt e completare con i seguenti valori: | ||
− | *<u>Recipient:</u> digitare "keybm" (Barbara Monticini) e selezionare come destinatario | + | *<u>Recipient:</u> digitare, dipendentemente dall'operatore che vi ha inviato la mail di attivazione, "keybm" (Barbara Monticini) oppure "keydl" (Mario Di Lorenzo) e selezionare come destinatario |
*<u>Message to encrypt:</u> scrivere a vostra scelta una password temporanea con cui sarà attivata la vostra utenza | *<u>Message to encrypt:</u> scrivere a vostra scelta una password temporanea con cui sarà attivata la vostra utenza | ||
*<u>Bottone [Encrypt]</u> per eseguire la cifratura del messaggio | *<u>Bottone [Encrypt]</u> per eseguire la cifratura del messaggio | ||
Riga 127: | Riga 164: | ||
I RAO creati da GARR CS sono autorizzati ad aggiungere ulteriori RAO e DRAO. | I RAO creati da GARR CS sono autorizzati ad aggiungere ulteriori RAO e DRAO. | ||
− | Dal menù principale scegliere la voce Settings > ''Admins''. La pagina presenta la tabella degli amministratori della vostra organizzazione (sia RAO che DRAO). | + | Dal menù principale scegliere la voce ''Settings'' > ''Admins''. La pagina presenta la tabella degli amministratori della vostra organizzazione (sia RAO che DRAO). |
Inizialmente la tabella include soltanto i due RAO nominati nel documento di adesione. | Inizialmente la tabella include soltanto i due RAO nominati nel documento di adesione. | ||
− | Per inserire un nuovo amministratore premere il bottone verde (+) (per il momento | + | Per inserire un nuovo amministratore premere il bottone verde (+) ('''<u>per il momento SCONSIGLIAMO l'aggiunta di amministratori con il bottone [Add IdP User]</u>'''). |
La maschera di creazione di un nuovo amministratore (Add New Client Admin) permette di inserire i dati dell'utente. | La maschera di creazione di un nuovo amministratore (Add New Client Admin) permette di inserire i dati dell'utente. | ||
Riga 137: | Riga 174: | ||
Compilare almeno i campi obbligatori: | Compilare almeno i campi obbligatori: | ||
− | *Username | + | *''Username'' |
*''Email'' | *''Email'' | ||
*''Forename'' | *''Forename'' | ||
Riga 158: | Riga 195: | ||
*Allow SSL auto approve | *Allow SSL auto approve | ||
− | '''Una nota speciale per | + | '''Una nota speciale per i seguenti 2 privilegi:''' |
*''Allow SSL auto approve'': se non abilitato, le richieste di certificati fatte da questo RAO dovranno essere sempre approvate dai RAO creati da GARR CS. | *''Allow SSL auto approve'': se non abilitato, le richieste di certificati fatte da questo RAO dovranno essere sempre approvate dai RAO creati da GARR CS. | ||
Riga 181: | Riga 218: | ||
Per modificare un amministratore già creato in precedenza selezionare dalla tabella degli amministratori la radio button relativa e premere il bottone [Edit]. | Per modificare un amministratore già creato in precedenza selezionare dalla tabella degli amministratori la radio button relativa e premere il bottone [Edit]. | ||
− | La maschera di modifica di un amministratore (Edit Client Admin) è sostanzialmente identica alla maschera di creazione nuovo amministratore. | + | La maschera di modifica di un amministratore (Edit Client Admin) è sostanzialmente identica alla maschera di creazione nuovo amministratore: sono presenti i TAB '''"Role & Privileges"''' e '''"Authentication"'''. Inoltre in alto a destra è presente il simbolo di una '''''Matita''''' che permette di accedere alla sezione in cui modificare i dati del profilo (email, telefono, indirizzo, città, cap, nazione). |
− | + | Rispetto alla maschera di creazione qui è presente la sezione con il link ''Reset password''. | |
===Reset della password=== | ===Reset della password=== | ||
Riga 189: | Riga 226: | ||
==Gestione Dominii== | ==Gestione Dominii== | ||
− | Per emettere certificati (sia a livello di Organizzazione che di Dipartimento) è prima di tutto necessario creare un dominio, delegarne la gestione alla propria organizzazione (e/o dipartimento) e validarlo. | + | ''Tempo di Lettura: '''5 minuti''''' |
+ | |||
+ | Per emettere certificati (sia a livello di Organizzazione che di Dipartimento) è prima di tutto necessario creare un dominio, delegarne la gestione alla propria organizzazione (e/o dipartimento) e validarlo. | ||
+ | |||
+ | Prima di inserire una nuovo dominio accertarsi che il dominio sia intestato all'Ente o che rispetti le regole specificate nella pagina [[TCSVerificaDomini]]. | ||
===Creazione dominio (sia ruolo RAO che DRAO)=== | ===Creazione dominio (sia ruolo RAO che DRAO)=== | ||
Riga 205: | Riga 246: | ||
Soluzione: creare i domini miodept.garr.it e *.miodept.garr.it -> attendere la delega del RAO -> la validazione è automatica | Soluzione: creare i domini miodept.garr.it e *.miodept.garr.it -> attendere la delega del RAO -> la validazione è automatica | ||
===Validazione dominio=== | ===Validazione dominio=== | ||
− | <blockquote>Per conoscere i metodi di validazione DCV è disponile il seguente articolo di Sectigo: https:// | + | <blockquote>Per conoscere i metodi di validazione DCV è disponile il seguente articolo di Sectigo: https://sectigo.com/knowledge-base/detail/Domain-Control-Validation-DCV-Methods/kA01N000000brbt </blockquote>Dal menù principale selezionare ''Domains'', selezionare il dominio da validare dalla lista dei domini disponibili e nel riquadro Domain Control Validation (''DCV)'' premere il bottone [Validate] ''. <u>'''Attenzione'''</u>'': possono essere validati solo i domini SENZA asterisco. |
− | <u>NOTA BENE</u>: Di default solo i primi 2 RAO di ogni nuova ORG creata in SCM hanno i permessi utili ad iniziare il DCV. Per tutti i successivi RAO, creati internamente da altri RAO, i privilegi vanno aggiunti manualmente da parte di un MRAO. Scrivere a <[mailto:garr-ca@garr.it garr-ca@garr.it]> (in cc | + | <u>'''NOTA BENE'''</u>: Di default solo i primi 2 RAO di ogni nuova ORG creata in SCM hanno i permessi utili ad iniziare il DCV. Per tutti i successivi RAO, creati internamente da altri RAO, i privilegi vanno aggiunti manualmente da parte di un MRAO. Scrivere a <[mailto:garr-ca@garr.it garr-ca@garr.it]> (in cc almeno un altro collega RAO) indicando il nominativo del RAO a cui far aumentare i privilegi. |
Nella finestra che si apre selezionare il metodo di validazione del dominio. Le scelte possibili sono ''Email'', ''HTTP, HTTPS, CNAME'', a seconda della scelta sono presentati requisiti diversi: | Nella finestra che si apre selezionare il metodo di validazione del dominio. Le scelte possibili sono ''Email'', ''HTTP, HTTPS, CNAME'', a seconda della scelta sono presentati requisiti diversi: | ||
Riga 214: | Riga 255: | ||
*''CNAME'': seguire le istruzioni che consistono nel creare un record DNS di tipo CNAME con il valore indicato sul dominio da validare | *''CNAME'': seguire le istruzioni che consistono nel creare un record DNS di tipo CNAME con il valore indicato sul dominio da validare | ||
− | <u>ATTENZIONE</u>: Prima di considerare l'impiego dei metodi HTTP / HTTPS leggere attentamente e capire le possibili implicazioni per i certificati widcard e per la validazione dei sottodomini nel documento: https://sectigo.com/resource-library/modifications-to-available-file-based-methods-of-domain-control-validation | + | <u>'''!!! ATTENZIONE !!!'''</u>: ''Prima di considerare l'impiego dei metodi HTTP / HTTPS '''leggere attentamente e capire''' le possibili implicazioni per i certificati widcard e per la validazione dei sottodomini nel documento:'' https://sectigo.com/resource-library/modifications-to-available-file-based-methods-of-domain-control-validation |
*''HTTP'': seguire le istruzioni che consistono nel creare un file txt contenente un codice generato da Sectigo e posizionarlo in una location '''well-known''' sul server web attivato sul dominio da validare. | *''HTTP'': seguire le istruzioni che consistono nel creare un file txt contenente un codice generato da Sectigo e posizionarlo in una location '''well-known''' sul server web attivato sul dominio da validare. | ||
*''HTTPS'': come per HTTP, ma la location sarà in HTTPS. | *''HTTPS'': come per HTTP, ma la location sarà in HTTPS. | ||
+ | Una volta scelto il metodo desiderato premere [Next] ed annotare le eventuali istruzioni presenti nella pagina successiva prima di premere il bottone [Submit] per avviare la validazione. Nella pagina principale che contiene i dettagli del dominio sarà possibile cancellare la richiesta di validazione e ripartire da capo premendo il bottone [simbolo del Cestino] alle voci ''DCV Status'' e ''DCV Order Status''.<blockquote>'''IMPORTANTE''' I dominii con prefisso <code>*.</code> sono validati contestualmente al dominio a cui sono associati ma graficamente lo saranno con uno o più giorni di attesa in più rispetto al dominio principale a cui sono collegati. </blockquote> | ||
+ | ===Rimozione / Cambio della Validazione dominio=== | ||
+ | Per cancellare una validazione non terminata o per cambiare il tipo di validazione (es. da EMAIL a CNAME, da HTTP a EMAIL) usare il simbolo del '''cestino''' accanto alla voce ''DCV Status'' che appare selezionando da ''Domains'' la checkbox del dominio su cui vogliamo operare. | ||
− | + | <u>In generale per i sottodomini non dovrebbe essere richiesto un processo di validazione separato perché di default ereditano la validazione del dominio padre.</u> | |
===Validazione annuale dei dominii=== | ===Validazione annuale dei dominii=== | ||
Riga 227: | Riga 271: | ||
La procedura di ri-validazione è identica alla DCV descritta in '''Validazione dominio'''. | La procedura di ri-validazione è identica alla DCV descritta in '''Validazione dominio'''. | ||
+ | |||
+ | ===Cancellazione di domini esistenti=== | ||
+ | Per cancellare un dominio da SCM scrivere a garr-ca@garr.it (mettendo in copia anche un altro collega RAO) ed indicare il nome del dominio da rimuovere. | ||
==Emissione Certificati== | ==Emissione Certificati== | ||
Quanto segue riguarda l'emissione di certificati tramite portale SCM da parte degli Admins, ovvero RAO e DRAO. | Quanto segue riguarda l'emissione di certificati tramite portale SCM da parte degli Admins, ovvero RAO e DRAO. | ||
− | Prima di procedere con la richiesta di certificati '' | + | Per informazioni sull'emissione automatizzata tramite ACME/certbot fare riferimento alla sezione [[GARRCS:GARR-TCS-4#ACME account|ACME account]]. |
+ | |||
+ | Prima di procedere con la richiesta di certificati ''GÉANT EV SSL'' e ''GÉANT EV Multi-Domain'' consigliamo di consultare la sezione dedicata più sotto. | ||
− | Per poter richiedere certificati '' | + | Per poter richiedere tutti i certificati di tipo ''GÉANT IGTF'' (grid, sia server che personali) è necessario compilare e validare il "''Secondary Organization Name''" seguendo le istruzioni della sezione dedicata più sotto. |
+ | |||
+ | <u>'''L'emissione di un certificato SSL deve sempre essere approvata da un RAO'''</u> (o DRAO, a seconda di come è stata organizzata la Org). | ||
+ | |||
+ | Se un RAO/DRAO ha nel proprio account la spunta sul privilegio "'''Allow SSL auto approve'''" (in ''Admin'' > cercare il RAO, selezionarlo e premere [Edit]) allora tutte le richieste di certificato da lui sottomesse saranno <u>automaticamente approvate</u> senza ulteriori passaggi. | ||
+ | |||
+ | In caso contrario le richieste dovranno essere approvate manualmente: | ||
+ | |||
+ | #alla ricezione della mail "'''SSL certificate for (<CN del certificato>) AWAITING APPROVAL'''" copiare il valore di '''Order Number''' | ||
+ | #in SCM, dal menù principale ''Certificates'' > ''SSL Certificate'' > cercare filtrando per '''Order Number''' > spuntare la riga ottenuta (che è in stato ''requested'') e proseguire premendo il bottone [APPROVE] . | ||
===Richiesta SSL Certificate ([https://support.sectigo.com/Com_KnowledgeDetailPage?Id=kA01N000000rfS7 What is a CSR?])=== | ===Richiesta SSL Certificate ([https://support.sectigo.com/Com_KnowledgeDetailPage?Id=kA01N000000rfS7 What is a CSR?])=== | ||
Riga 250: | Riga 308: | ||
openssl req -nodes -newkey rsa:3072 -keyout myserver.key -out server.csr -subj "/C=IT/CN=mysubdomain.mydomain.com" | openssl req -nodes -newkey rsa:3072 -keyout myserver.key -out server.csr -subj "/C=IT/CN=mysubdomain.mydomain.com" | ||
− | '''''Certficate Profile:''''' selezionare '' | + | '''''Certficate Profile:''''' selezionare ''GÉANT OV SSL'' per un certificato SSL per un solo nome di dominio o ''GÉANT OV Multi-Domain'' per aggiungere SAN (Subject Alternative Names). <blockquote><u>'''Importante'''</u>: nei certificati ''GÉANT OV SSL'' viene aggiunto in automatico un Subject Alternative Names che riporta il valore del CN ed eventualmente la versione con prefisso www. . Per questo motivo consigliamo di richiedere certificati ''GÉANT OV Multi-Domain'' anche quando la richiesta presenta un solo fqdn.</blockquote>Completare la richiesta indicando gli eventuali SAN (''Subject Alternative Names'') nel caso si stia richiedendo un certificato ''GÉANT OV Multi-Domain''. Di default sono presi direttamente dalla CSR ma possono anche essere aggiunti manualmente in questa fase (''Use commas or spaces to separate multiple values for bulk input.'') |
Nella schermata successiva ci verrà richiesto se abilitare o meno il rinnovo automatico, ''Enable auto renewal of this certificate'', e quanti giorni prima iniziare il processo. | Nella schermata successiva ci verrà richiesto se abilitare o meno il rinnovo automatico, ''Enable auto renewal of this certificate'', e quanti giorni prima iniziare il processo. | ||
− | ====Certificati Extended Validation ('' | + | E' sempre possibile verificare tramite SCM se per un certificato è stato abilitato l'auto-rinnovo: dal menù principale ''Certificates'' > ''SSL Certificate'' > cercare filtrando per il nome del server > spuntare la riga del certificato in corso di validità (di solito ISSUED e in verde) e premere [View]. Se nei dettagli appare <u>Auto-renew SUCCESSFUL</u> o <u>Auto-renew SCHEDULED</u> allora l'auto-rinnovo è stato impostato. Nella sezione ''Details'' del certificato è possibile vedere chi è l'owner del certificato selezionando la voce ''Owner''. |
+ | |||
+ | ====Certificati Extended Validation (''GÉANT EV SSL'' e ''GÉANT EV Multi-Domain)''==== | ||
Nonostante questo tipo di certificato possa essere richiesto attraverso il modulo standard di richiesta certificati vi preghiamo di considerare la possibilità di validare a priori l'emissione dei certificati EV per la vostra Organizzazione grazie al meccanismo chiamato ''EV Anchor''. | Nonostante questo tipo di certificato possa essere richiesto attraverso il modulo standard di richiesta certificati vi preghiamo di considerare la possibilità di validare a priori l'emissione dei certificati EV per la vostra Organizzazione grazie al meccanismo chiamato ''EV Anchor''. | ||
Riga 261: | Riga 321: | ||
<u>Cosa succede se non sfrutto il meccanismo ''EV Anchor''?</u> Per ogni nuova richiesta di certificato EV si dovrà contattare il team di validazione Sectigo attraverso il sistema di ticketing https://sectigo.com/support-ticket. | <u>Cosa succede se non sfrutto il meccanismo ''EV Anchor''?</u> Per ogni nuova richiesta di certificato EV si dovrà contattare il team di validazione Sectigo attraverso il sistema di ticketing https://sectigo.com/support-ticket. | ||
− | <u>La mia organizzazione vuole attivare ''EV Anchor'', cosa dobbiamo fare?</u> Stabilire l'elenco dei domini per i quali il vostro Ente è interessato a ottenere certificati EV e assicurarsi di aver creato i domini all'interno del portale SCM. Per capire in cosa consiste la validazione EV consultare | + | <u>La mia organizzazione vuole attivare ''EV Anchor'', cosa dobbiamo fare?</u> Stabilire l'elenco dei domini per i quali il vostro Ente è interessato a ottenere certificati EV e assicurarsi di aver creato i domini all'interno del portale SCM. Per capire in cosa consiste la validazione EV consultare la documentazione: [https://www.sectigo.com/knowledge-base/detail/What-is-an-Extended-Validation-EV-certificate-1527076098604/kA01N000000zFOz Sectigo Extended Validation Explained]. In seguito contattare <[mailto:garr-ca@garr.it garr-ca@garr.it]> per gli ulteriori passaggi. |
+ | |||
+ | ====Certificati ''GÉANT IGTF Multi Domain (grid)''==== | ||
+ | Per poter richiedere certificati ''GÉANT IGTF Multi Domain'' (grid) è necessario validare il "''Secondary Organization Name''". Per procedere: scrivere un ticket a <garr-ca@garr.it> per chiedere agli amministratori MRAO di compilare il campo "''Secondary Organization Name''". Nello scegliere il valore del campo prestare attenzione che contenga solo caratteri ASCII. Se, già con Digicert, venivano emessi certificati "grid utente" assicurarsi di impostare il campo "Secondary Organization Name" identico al campo O usato con Digicert (in caso di dubbio consultare il portale Digicert per controllo). <u>Motivazione:</u> <u>Dato che il subject dei certificati grid utente è usato come "username" è fondamentale che questo rimanga inalterato per non causare problemi agli utenti nell'accesso alla grid.</u> Gli amministratori MRAO faranno contestualmente partire la validazione del "''Secondary Organization Name''" che permetterà dipoter iniziare a richiedere certificati grid. | ||
+ | |||
+ | A partire dal giorno 3 Ottobre 2020 non più possibile personalizzare i campi presenti nel ''distinguished name'' (DN) dei certificati emessi. Su richiesta della comunità GÉANT TCS i certificati IGTF sono emessi con uno speciale "Certificate Profile" che '''<u>non include</u>''' nel DN i campi ''streetAddres'', ''postalCode'' e ''stateProvince''. | ||
+ | |||
+ | ====Richiesta certificati SSL tramite autenticazione SAML (per utenti non admin)==== | ||
+ | È possibile richiedere certificati SSL con autenticazione basata su autenticazione federata SAML via IDEM. In questo modo sarà possibile far richiedere i certificati anche ad utenti che non siano RAO o DRAO. Nel portale SCM questa funzionalità è definita ''Self Enrollment''. | ||
+ | |||
+ | Per abilitare il ''Self Enrollment'' selezionate dal Menù principale ''Enrollments'', poi premere il bottone [(+)]. | ||
+ | |||
+ | Nella finestra che si aprirà selezionare "''SSL SAML self-enrollment form",'' dare un nome all'Endpoint e premere [Next] | ||
+ | |||
+ | Nella finestra successiva generare la "URI Extension" premendo il bottone [Generate]. | ||
+ | |||
+ | '''Come funziona''': L'accesso averrà tramite la URL generata (mostrata in Endpoint URL) e con autenticazione SAML. In questo modo l'accesso sarà limitato ai soli utenti della propria organizzazione e tutti gli accessi saranno autenticati su base personale. | ||
+ | |||
+ | '''Raccomandiamo''' di non spuntare la casella ''Automatically Approve Self Enrollment Requests'' per mantenere il controllo delle richieste di certificati SSL richiesti tramite ''Self Enrollment''. È inoltre possibile limitare i tipi di certificati che si possono richiedere tramite la scelta dei <u>Profili</u> associati all'Endpoint (tabella ''Profiles''). | ||
+ | |||
+ | Una volta terminata la configurazione del ''Self Enrollment'' premendo il bottone [Save], distribuire ai colleghi le URL del nuovo Endpoint per la richiesta dei certificati. | ||
+ | |||
+ | =====SSL Certificate Enrollment: accesso ed emissione===== | ||
+ | Gli utenti che accederanno alle URL del SSL Certificate Enrollment dovranno autenticarsi tramite il proprio Identity Provider. | ||
+ | |||
+ | Una volta acceduti dovranno selezionare il ''Certificate Type'', il ''Certificate Term'' ed il ''Server Software'' per cui stanno richiedendo il certificato ed incollare la Certificate Signing Request nel campo ''CSR'', i campi rimanenti sono opzionali. Una volta premuto il bottone [ENROLL] il RAO riceverà una notifica di richiesta e potrà approvare la richiesta del certificato dal menù ''Certificates'' del portale SCM. | ||
+ | |||
+ | Una volta approvata la richiesta ed emesso il certificato, l'utente riceverà infine un messaggio di posta elettronica contenente i link per scaricare il certificato richiesto. | ||
+ | |||
+ | ===Approvazione di Richieste per SSL Certificate=== | ||
+ | <u>'''L'emissione di un certificato SSL deve sempre essere approvata da un RAO'''</u> (o DRAO, a seconda di come è stata organizzata la Org). | ||
+ | |||
+ | Se un RAO/DRAO ha nel proprio account la spunta sul privilegio "'''Allow SSL auto approve'''" (in ''Admin'' > cercare il RAO, selezionarlo e premere [Edit]) allora tutte le richieste di certificato da lui sottomesse saranno <u>automaticamente approvate</u> senza ulteriori passaggi. | ||
+ | |||
+ | In caso contrario le richieste dovranno essere approvate manualmente: | ||
+ | |||
+ | #alla ricezione della mail "'''SSL certificate for (<CN del certificato>) AWAITING APPROVAL'''" copiare il valore di '''Order Number''' | ||
+ | #in SCM, dal menù principale ''Certificates'' > ''SSL Certificate'' > cercare filtrando per '''Order Number''' > spuntare la riga ottenuta (che è in stato ''requested'') e proseguire premendo il bottone [APPROVE] . | ||
+ | |||
+ | ===Installazione SSL Certificate=== | ||
+ | Dopo aver installato il certificato <u>verificare</u> di aver configurato in maniera ottimale la ''certificate chain'' con uno dei seguenti 2 metodi: | ||
+ | |||
+ | #testando la configurazione in https://www.ssllabs.com/ssltest/ | ||
+ | #usando il comando OpenSSL: <code>openssl s_client -connect myserver.mydomain.org:443</code> | ||
− | + | <u>Interpretare</u> i risultati: | |
− | |||
− | + | #tra i risultati del test Qualys SSL Labs cercare la voce "'''Chain issues'''" ed assicurarsi che sia visualizzato il valore "'''None'''" | |
− | + | #l'output del comando Openssl deve contenere solo la seguente ''certificate chain'': | |
− | Per | + | <code>Certificate chain</code> |
+ | |||
+ | <code>0 s:C = IT, O = Consortium GARR, CN = cert.test.garr.it</code> | ||
+ | |||
+ | <code> i:C = NL, O = GEANT Vereniging, CN = GEANT OV RSA CA 4</code> | ||
+ | |||
+ | <code>1 s:C = NL, O = GEANT Vereniging, CN = GEANT OV RSA CA 4</code> | ||
+ | |||
+ | <code> i:C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority</code> | ||
+ | |||
+ | <u>Soluzione</u>: | ||
+ | |||
+ | Per correggere eventuali problemi configurare come ''certificate chain'' solo i certificati delle CA intermedie di GÉANT (ad esempio CN = GEANT OV RSA CA 4 e simili). | ||
+ | |||
+ | ===Consultazione dei certificati SSL=== | ||
+ | Oltre al portale SCM di Sectigo in cui ogni RAO e DRAO può consultare rispettivamente lo status dei certificati della propria ''Organization'' e del proprio ''Department'', esiste anche un portale open source disponibile a tutta la comunità internet. Il portale è raggiungibile all'indirizzo https://crt.sh/ e la ricerca può avvenire sulla base dei più svariati parametri (''Domain Name'', ''Organization Name'', ''Certificate Fingerprint'' e tutti quelli inclusi nella sezione ''Advanced''). | ||
+ | |||
+ | ===Richiesta Client Certificate via SCM con invito (solo per <s>GÉANT IGTF-Classic-Robot Email</s> "GÉANT Organisation Automated Authentication")=== | ||
+ | La richiesta di Client Certificate da parte degli Admin via portale SCM è piuttosto scomoda e soprattutto non scalabile per un numero elevato di certificati. La '''soluzione consigliata''' è la richiesta via <u>autenticazione federata con SAML</u> (vedi paragrafo successivo). | ||
+ | |||
+ | '''L'unico tipo di certificato ordinabile in SCM''' è <s>"GÉANT IGTF-Classic-Robot Email"</s> "GÉANT Organisation Automated Authentication" e trattandosi di un certificato IGTF è necessario <u>configurare la propria Org per la richiesta di ''certificati IGTF (grid):''</u> | ||
+ | |||
+ | *Scrivere una mail a <[mailto:garr-ca@garr.it garr-ca@garr.it]> per chiedere agli amministratori MRAO di modificare e far partire la validazione del "Secondary Organization Name". | ||
+ | *Comunicare nella mail il valore del campo "Secondary Organization Name" prestando attenzione che contenga solo caratteri ASCII e che sia identico al campo O eventualmente usato in precedenza per i certificati grid con Digicert (in caso di dubbio consultare il portale Digicert per controllo). ''Dato che il subject dei certificati grid è usato come "username" è fondamentale che questo rimanga inalterato per non causare problemi di accesso alla grid per gli utenti.'' | ||
+ | |||
+ | Per richiedere un certificato <s>"GÉANT IGTF-Classic-Robot Email"</s> "GÉANT Organisation Automated Authentication" via SCM per un membro della propria organizzazione selezionare ''Persons'' e premere il bottone verde (+). Se la persona fosse già stata creata in precedenza selezionare la riga corrispondente e saltare direttamente più sotto alle istruzioni relative al TAB '''Enrolment Invitation'''. | ||
Nella finestra che si apre devono essere indicati o confermati: | Nella finestra che si apre devono essere indicati o confermati: | ||
− | *Organization | + | *Organization ed eventualmente Department, |
*alla voce Domain va selezione il dominio su cui emettere il certificato, | *alla voce Domain va selezione il dominio su cui emettere il certificato, | ||
− | |||
− | |||
*in First Name il nome proprio ed in Last Name il cognome. | *in First Name il nome proprio ed in Last Name il cognome. | ||
− | *in | + | *in Email Address va inserita la parte locale (a sinistra della @domain) dell'indirizzo di posta che sarà associato al certificato. |
+ | |||
+ | Proseguire con [Next] | ||
− | + | *in Common Name inserire il nome dell'utente che verrà visualizzato nel certificato | |
− | + | *(opzionale) in Secret impostare un valore specifico per questo utente. | |
− | + | Una volta terminato l'inserimento premere il bottone [Save]. | |
− | + | Selezionare il nuovo utente creato e premere il bottone [Edit]. | |
− | ===Richiesta Client Certificate con portale self-service via SAML | + | |
+ | Proseguire nel TAB '''Enrolment Invitation''' | ||
+ | |||
+ | *Premere (+) su Invitation per creare l'invito | ||
+ | *Compilare i parametri dell'invito considerando che <u>l'unico Certificate Profile funzionante è '''<s>GÉANT IGTF-Classic-Robot Emai</s>l GÉANT Organisation Automated Authentication'''</u>) | ||
+ | |||
+ | Una volta terminato l'inserimento premere il bottone [Save]. | ||
+ | |||
+ | Se la configurazione è andata a buon fine allora la persona riceverà una mail con oggetto "'''Invitation Email - You have requested email certificate validation'''" contenente le istruzioni per richiedere il certificato. | ||
+ | |||
+ | Ricordiamo che l'unico profilo funzionante è <u>'''GÉANT Organisation Automated Authentication'''</u> e la scelta di qualsiasi altro Profilo produrrà un errore. | ||
+ | ===Richiesta Client Certificate con portale self-service via SAML=== | ||
Il portale per la richiesta self-service dei certificati personali (client certificate), personali IGTF (email e robot) è https://cert-manager.com/customer/garr/idp/clientgeant | Il portale per la richiesta self-service dei certificati personali (client certificate), personali IGTF (email e robot) è https://cert-manager.com/customer/garr/idp/clientgeant | ||
− | L'accesso è possibile solo tramite autenticazione federata con [https://www.idem.garr.it IDEM] e previa configurazione dell'Identity Provider istituzionale (sezione '''Configurazione SAML'''). | + | <u>L'accesso è possibile solo tramite autenticazione federata con [https://www.idem.garr.it IDEM] e previa configurazione dell'Identity Provider istituzionale (sezione '''Configurazione SAML''').</u> |
+ | |||
+ | Dal 1 settembre 2023 sono entrate in vigore nuove regole relative al rilascio dei certificati personali emessi da CA pubbliche secondo quanto specificato dal documento <nowiki>https://cabforum.org/wp-content/uploads/CA-Browser-Forum-SMIMEBR-1.0.0.pdf</nowiki> | ||
+ | |||
+ | Per emettere certificati S/MIME ("'''GÉANT Personal email signing and encryption'''") è necessario l'Organizzazione in SCM sia stata rivalidata dopo il 1 settembre 2023. Tra i requisiti introdotti dalle nuove regole S/MIME: la persona che richiede il certificato deve avere associato in SCM una ''Person'' con ''Validation Type'' = HIGH e nei campi Nome e Cognome deve essere presente il nome e cognome di una persona concreta . | ||
+ | |||
+ | Per emettere certificati IGTF/grid ("'''GÉANT Personal Authentication'''" e "'''GÉANT Personal Automated Authentication'''") è necessario l'Organizzazione abbia impostato in SCM un ''Secondary Organization Name'' e che questo sia stato validato. | ||
+ | |||
+ | Le nuove root e intermediate CA di Géant sono disponibili in: https://wiki.geant.org/display/TCSNT/TCS+Trust+Anchors+and+Intermediates | ||
====Configurazioni==== | ====Configurazioni==== | ||
Riga 296: | Riga 442: | ||
*L'Identity Provider deve rilasciare un determinato insieme di attributi al Service Provider Sectigo. Dettagli nella sezione '''Configurazione SAML''' | *L'Identity Provider deve rilasciare un determinato insieme di attributi al Service Provider Sectigo. Dettagli nella sezione '''Configurazione SAML''' | ||
− | *In SCM, selezionare | + | *In SCM, selezionare ''Organizations,'' selezionare la propria organizzazione e premere il bottone [Edit]. Nella finestra di modifica editare il campo "Academic code (SCHAC Home Organization)" inserendo il valore stabilito per l'attributo schacHomeOrganization rilasciato dall'Identity Provider. Generalmente coincide con il valore del dominio principale, o ''scope'', ma conviene coordinarsi con l'idp manager. |
<u>Configurare anche la richiesta di ''certificati IGTF (grid)''</u> | <u>Configurare anche la richiesta di ''certificati IGTF (grid)''</u> | ||
− | * | + | *Scrivere un ticket a <[mailto:garr-ca@garr.it garr-ca@garr.it]> per chiedere agli amministratori MRAO di modificare e far partire la validazione del "Secondary Organization Name". |
− | + | *Comunicare nel ticket il valore del campo "Secondary Organization Name" prestando attenzione che contenga solo caratteri ASCII e che sia identico al campo O eventualmente usato in precedenza per i certificati grid con Digicert (in caso di dubbio consultare il portale Digicert per controllo). ''Dato che il subject dei certificati grid è usato come "username" è fondamentale che questo rimanga inalterato per non causare problemi di accesso alla grid per gli utenti.'' | |
− | ====Richiesta client certificate tramite portale self-service==== | + | ====Richiesta di client certificate tramite portale self-service via IDEM/SAML==== |
#Andare su https://cert-manager.com/customer/garr/idp/clientgeant ed autenticarsi con il proprio IDP. | #Andare su https://cert-manager.com/customer/garr/idp/clientgeant ed autenticarsi con il proprio IDP. | ||
#Selezionare il tipo di certificato: | #Selezionare il tipo di certificato: | ||
− | #*"GÉANT Personal | + | #*"'''GÉANT Personal email signing and encryption'''" certificati personali emessi da un CA pubblica per la firma e la cifratura di email ma <u>non</u> per la firma di documenti o la client authentication. [<u>Il Profilo,</u> anche se disponibile nel menù a tendina<u>, permette l'emissione dei certificati solo se la Org è stata rivalidata dopo il 1 settembre 2023]</u> |
− | #*"GÉANT | + | #**'''Novità da settembre 2023''': |
− | #*"GÉANT | + | #***la persona (''Persons'') che richiede il certificato via SAML acquisisce (in automatico) la proprietà ''"'''Validation Type"''''' '''= HIGH''' ed i campi First e Last Name vengono sovrascritti se diversi dai valori degli attributi SAML ''givenName'' e ''sn'' trasmessi dall'Identity Provider. Usare https://cert-manager.com/customer/garr/ssocheck/ per conoscere quali valori degli attributi SAML givenName e sn sono trasmessi dall'Identity Provider. |
+ | #***La generazione del certificato impiega più di un minuto per completare. | ||
+ | #*"'''GÉANT Personal Authentication'''" certificati personali emessi da una CA privata da usare in ambito grid/IGTF e per la client authentication. <u>Non</u> adatti per la firma e la cifratura di email e per la firma di documenti. [<u>Il Profilo,</u> anche se disponibile nel menù a tendina<u>, permette l'emissione dei certificati solo se la Org ha impostato e validato il ''Secondary Organization Name''</u>] | ||
+ | #*"'''GÉANT Personal Automated Authentication'''" certificati personali robot emessi da una CA privata da usare in agenti software che si autenticano per conto dell'utente (ambito grid/IGTF). Non adatti per la firma e la cifratura di email e per la firma di documenti. [<u>Il Profilo,</u> anche se disponibile nel menù a tendina<u>, permette l'emissione dei certificati solo se la Org ha impostato e validato il ''Secondary Organization Name''</u>] | ||
#Selezionare se si desidera che la chiave privata sia generata server-side o localmente: | #Selezionare se si desidera che la chiave privata sia generata server-side o localmente: | ||
#*Scegliere "Generate RSA" se si vuole un certificato con chiave privata generata server-side. | #*Scegliere "Generate RSA" se si vuole un certificato con chiave privata generata server-side. | ||
Riga 315: | Riga 464: | ||
#*'''RACCOMANDATO''' Scegliere "Upload CSR" se <u>non</u> si vuole che la chiave privata sia generata server-side ma si vuole fornire una CSR generata in autonomia. | #*'''RACCOMANDATO''' Scegliere "Upload CSR" se <u>non</u> si vuole che la chiave privata sia generata server-side ma si vuole fornire una CSR generata in autonomia. | ||
#**Di seguito trovate le istruzioni per la creazione della chiave e della CSR con OpenSSL: | #**Di seguito trovate le istruzioni per la creazione della chiave e della CSR con OpenSSL: | ||
− | #***Creazione CSR con chiave RSA a | + | #***Creazione CSR con chiave RSA a 3072 bit: <code>openssl req -newkey rsa:3072 -keyout nome_cognome-key.pem -out nome_cognome-csr.pem -subj "/CN=Nome Cognome"</code> |
#***Creazione CSR con chiave ECC a 256bit: <code>openssl req -newkey ec:<(openssl ecparam -name prime256v1) -keyout nome_cognome-key.pem -out nome_cognome-csr.pem -subj "/CN=Nome Cognome"</code> | #***Creazione CSR con chiave ECC a 256bit: <code>openssl req -newkey ec:<(openssl ecparam -name prime256v1) -keyout nome_cognome-key.pem -out nome_cognome-csr.pem -subj "/CN=Nome Cognome"</code> | ||
#*Se si è scelto di generare il certificato server-side è necessario compilare il campo password con cui sarà cifrato il file PKCS#12 generato per voi. | #*Se si è scelto di generare il certificato server-side è necessario compilare il campo password con cui sarà cifrato il file PKCS#12 generato per voi. | ||
+ | #Choose key protection algorithm: "Compatible TripleDES-SHA1" | ||
#Premere "Submit" e accettare il contratto di licenza. | #Premere "Submit" e accettare il contratto di licenza. | ||
#In pochi istanti avverrà il download del certificato. Il formato dipende dalle scelte fatte durante la richiesta: | #In pochi istanti avverrà il download del certificato. Il formato dipende dalle scelte fatte durante la richiesta: | ||
#*Con "Generate RSA/ECC", si riceverà un file PKCS#12 con nome '''certs.p12''' contenente chiave privata e certificato (file cifrato con la password scelta). Tale certificato potrà essere importato nel browser e nel client di posta con la funzione "Import Certificate" o similare. | #*Con "Generate RSA/ECC", si riceverà un file PKCS#12 con nome '''certs.p12''' contenente chiave privata e certificato (file cifrato con la password scelta). Tale certificato potrà essere importato nel browser e nel client di posta con la funzione "Import Certificate" o similare. | ||
#*Con "Upload CSR", si riceverà un file PEM-formatted chiamato '''certs.pem''' e contenente il certificato personale, il certificato intermedio della CA ed il root certificate di Sectigo . Per poter utilizzare il certificato per la firmare e crittografare i messaggi di posta elettronica è necessario creare un file in formato PKCS#12 contenente sia il certificato, sia la chiave. E' possibile farlo utilizzando OpenSSL con il seguente comando: <code>openssl pkcs12 -export -in certs.pem -inkey nome_cognome-key.pem -out nome_cognome.p12</code> | #*Con "Upload CSR", si riceverà un file PEM-formatted chiamato '''certs.pem''' e contenente il certificato personale, il certificato intermedio della CA ed il root certificate di Sectigo . Per poter utilizzare il certificato per la firmare e crittografare i messaggi di posta elettronica è necessario creare un file in formato PKCS#12 contenente sia il certificato, sia la chiave. E' possibile farlo utilizzando OpenSSL con il seguente comando: <code>openssl pkcs12 -export -in certs.pem -inkey nome_cognome-key.pem -out nome_cognome.p12</code> | ||
+ | |||
+ | ===Gestione dei Certificati Personali=== | ||
+ | Le risorse messe a disposizione da Sectigo sono molto carenti per quanto riguarda la gestione dei certificati personali per l'utente finale. | ||
+ | |||
+ | Il RAO rappresenta il punto di riferimento unico per poter consultare lo status dei certificati personali emessi a nome di un utente. | ||
+ | |||
+ | <s>'''Ogni utente può avere attivi al massimo due certificati per tipologia.''' A partire dal terzo certificato emesso nella stessa tipologia, se il computo totale dei certificati attivi equivalesse a 3, <u>verrà revocato automaticamente da Sectigo il certificato più vecchio</u> ancora valido in quella tipologia.</s> | ||
+ | |||
+ | ====Revoca dei certificati personali==== | ||
+ | La revoca può essere richiesta ad uno dei RAO della proprio Organizzazione o tramite ticket al supporto di Sectigo https://sectigo.com/support-ticket. | ||
+ | |||
+ | I certificati emessi prima del 18 Marzo 2022 possono essere revocati solo tramite ticket al supporto di Sectigo https://sectigo.com/support-ticket. | ||
+ | |||
+ | ====Verificare se un certificato personale è stato revocato==== | ||
+ | Esistono due modi per scoprire questa informazione: | ||
+ | |||
+ | *contattare uno dei RAO della propria Organizzazione; | ||
+ | *consultare la cosiddetta CRL ovvero l'elenco dei certificati revocati dalla CA. Il procedimento da seguire è indicato qui sotto. | ||
+ | |||
+ | E' necessario disporre dei seguenti elementi: | ||
+ | |||
+ | *software '''Openssl''' | ||
+ | *'''certificato personale''' salvato su file (da cui ricavare il '''serial number''', istruzioni fornite qui sotto) | ||
+ | *'''file CRL''' (la cui location è ricavabile dal file precedente, istruzioni fornite qui sotto) | ||
+ | |||
+ | Salvare il certificato personale su file (ad esempio "cert.crt") estraendolo dal proprio ''Browser'' o dal proprio ''Client di Posta'' (seguire le istruzioni del software in uso). | ||
+ | |||
+ | Per ricavare la location della CRL eseguire il comando '''openssl''': | ||
+ | ''openssl x509 -in cert.crt -noout -text | grep crl'' | ||
+ | Appena ottenuta la <u>url della crl</u> scaricarla con il comando '''wget''': | ||
+ | ''wget <url-ottenuta-dal-comando-precedente>'' | ||
+ | Estrarre il '''serial number''' del proprio certificato personale con il seguente comando: | ||
+ | ''openssl x509 -in cert.crt -noout -serial'' | ||
+ | Adesso è possibile scoprire se il '''serial number''' del nostro certificato è stato revocato: | ||
+ | ''openssl crl -inform DER -text -in [name of downloaded CRL] | grep [serial number of client's certificate you would like to check]'' | ||
+ | |||
+ | =====Esempio a partire da un file .p12:===== | ||
+ | openssl pkcs12 -in ../Desktop/certificato.p12 -nokeys -out certificato.crt | ||
+ | |||
+ | openssl x509 -in certificato.crt -noout -text | grep crl | ||
+ | URI:<nowiki>http://pippo-pluto-paperino.crl</nowiki> | ||
+ | |||
+ | wget <nowiki>http://pippo-pluto-paperino.crl</nowiki> | ||
+ | |||
+ | openssl x509 -in certificato.crt -noout -serial | ||
+ | serial=BD8DFB1FE2EEF98C7329CEE026C38009 | ||
+ | |||
+ | openssl crl -inform DER -text -in pippo-pluto-paperino.crl | grep BD8DFB1FE2EEF98C7329CEE026C38009 | ||
+ | '''<u>Se la stringa non viene trovata allora il certificato non è stato revocato.</u>''' | ||
+ | |||
+ | '''<u>Se invece viene visualizzato il serial number allora il certificato è stato revocato. Come nel caso seguente:</u>''' | ||
+ | openssl crl -inform DER -text -in pippo-pluto-paperino.crl | grep BD8DFB1FE2EEF98C7329CEE026C38009 | ||
+ | Serial Number: BD8DFB1FE2EEF98C7329CEE026C38009 | ||
+ | |||
+ | ===Richiesta Document Signing Certificate=== | ||
+ | E' possibile ordinare certificati Document Signing su un token USB preconfigurato da Sectigo. | ||
+ | |||
+ | I costi dei token USB non sono coperti dal servizio TCS e sono a carico del richiedente. | ||
+ | |||
+ | Per fare un ordine collegarsi a: https://www.sectigo.com/ssl-certificates-tls/document-signing-certificates e usare il codice sconto: '''QQY1XB49V9''' | ||
===Richiesta Code Signing Certificate=== | ===Richiesta Code Signing Certificate=== | ||
− | |||
− | + | ====Descrizione del servizio a partire da maggio 2023==== | |
+ | <blockquote>Dall'<nowiki/>'''8 maggio 2023''' sarà possibile ordinare certificati ''Code Signing'' '''solo''' impiegando '''device''' '''FIPS''' conformi a specifici standard HSM oppure direttamente su '''token''' forniti da Sectigo. | ||
− | + | '''<u>Uso di dispositivi propri</u>''' - Se si intende usare dispositivi propri, considerare nell'acquisto che solo i seguenti sono supportati: | |
− | + | *Thales/Safenet Luna netHSM (<u>solo per chiavi RSA</u>) - deve essere un Luna: Luna HSM V7.x e Luna Cloud HSM (https://cpl.thalesgroup.com/it/encryption/hardware-security-modules/network-hsms) | |
+ | *Yubico FIPS Yubikeys (<u>solo per chiavi ECC</u>) - https://www.yubico.com/products/yubikey-fips/ | ||
− | + | '''<u>Acquisto di dispositivi da Sectigo</u>''' - I costi dei token USB non sono coperti dal servizio TCS e sono a carico del richiedente. | |
− | + | Per fare un ordine collegarsi a: https://www.sectigo.com/ssl-certificates-tls/code-signing e usare il codice sconto: '''2GE8AFN0T1''' | |
− | + | '''<u>Dispositivi non supportati</u>''' - Se si dispone di un dispositivo specifico che non è attualmente supportato, si prega di informare <[mailto:garr-ca@garr.it garr-ca@garr.it]>. | |
− | + | <u>Ulteriori informazioni e guide sono disponibili qui</u>: https://sectigo.com/knowledge-base/detail/Changes-to-Sectigo-Code-Signing-Offerings/kA03l000000BoIs.</blockquote> | |
− | E' | + | ====Istruzioni a partire da Maggio 2023==== |
+ | E' stato creato sul portale SCM di GARR un nuovo Profilo specifico per richiedere i certificati Code Signing su dispositivi FIPS già posseduti "''HSM Code Signing''". | ||
− | + | Il Profilo "''SECTIGO Public CA CS Certificate Profile''" per l'acquisto dei certificati emessi su dispositivo FIPS e spediti da Sectigo è stato disabilitato nel Portale SCM (contattare [mailto:garr-ca@garr.it garr-ca@garr.it] per l'abilitazione). | |
− | + | =====(''Solo la prima volta'') Creazione da parte del RAO di un Account per certificati su dispositivo FIPS già posseduto===== | |
+ | Uno dei <u>RAO</u> deve creare un '''<u>Account</u>''' per la propria ORG seguendo il percorso dal Menù Principale ''Enrollment'' >> ''Enrollment Forms.'' Da qui spuntare la voce "Code Signing certificate on supported HSM". In alto apparirà il bottone [''Accounts'']. Premendo sul bottone si aprirà la finestra "''Code Signing Web Form Accounts''" che contiene la lista degli Account già creati dalla community GARR TCS. Creare il nuovo Account tramite il bottone verde (+) in alto a destra e compilando i campi della form come segue: | ||
− | === | + | *''Name'' = HSM Code Signing <nome ORG> |
− | + | ||
+ | *''Organization'' = scegliere la propria tramite menù a tendina | ||
+ | *''Department'' = (opzionale) | ||
+ | *''Profiles'' = "HSM Code Signing" | ||
+ | *''CSR Generation Method'' = "Provided by user" | ||
+ | |||
+ | Salvare le impostazioni e ritornare al Menù Principale. | ||
+ | |||
+ | =====(''Per ogni nuovo certificato Code Signing su dispositivo FIPS già posseduto'') Creazione di un invito da parte del RAO===== | ||
+ | Uno dei <u>RAO</u> deve creare un Invito per il richiedente seguendo il percorso dal Menù Principale ''Certificates'' >> ''Code Signing Certificates.'' | ||
+ | |||
+ | Cliccare sul bottone in alto a destra ''[Invitations].'' | ||
+ | |||
+ | Si aprirà una finestra pop-up chiamata "Invitations" in cui per proseguire è necessario premere il bottone verde [+] in alto a destra. | ||
+ | |||
+ | Si aprirà una maschera che permette l'inserimento dei dati della persona che richiede il certificato Code Signing. | ||
− | + | *Compilare il campo ''Email'' con l'indirizzo email del richiedente. | |
− | + | *Compilare ''Enrollment Endpoint'' selezionando dal menù la voce "<u>Code Signing certificate on supported HSM</u>". | |
+ | *Compilare ''Account'' scegliendo dal menù l'account creato per la propria ORG (esempio "HSM Code Signing <nome-org>") | ||
− | + | Completare il processo cliccando su "''Send''". Il richiedente riceverà una mail con le istruzioni e il link per procedere alla creazione del certificato. | |
− | + | =====(''Per ogni nuovo certificato Code Signing su dispositivo FIPS già posseduto'') Creazione della CSR e della Key Attestation da parte dell'utente===== | |
− | + | Inizializzare il dispositivo HSM secondo le istruzioni del Produttore personalizzando PIN, PUK e Key Management (!!! <u>non lasciare i valori di default</u> !!!) | |
− | < | + | Seguire le istruzioni di Sectigo presenti in questa Guida "'''<u>Sectigo_CodeSigningCertificate_AdminGuide_Enterprise</u>'''" sezione "3. ''CSR and Key Attestation Creation''", scaricabile in fondo a questo link https://sectigo.com/knowledge-base/detail/Changes-to-Sectigo-Code-Signing-Offerings/kA03l000000BoIs. |
− | < | + | <u>Note sull'uso di Yubico Yubikeys:</u> |
− | <code> | + | *Usare solo '''YubiKey 5 FIPS Series''' |
+ | *Usare solo algoritmi '''ECC''' | ||
+ | *La shell deve essere avviata con permessi di '''Administrator''' | ||
+ | *Il comando <code>type attestation.crt intermediateCA.crt > attestation.pem</code> potrebbe introdurre caratteri non idonei che impediscono successivamente di sottomettere la richiesta. Ottenere la concatenazione dei file usando Notepad (o qualsiasi altro software) con permessi amministrativi. | ||
+ | *Il comando <code>findstr /v CERTIFICATE attestation.b64 > attestation.b64</code> può essere sostituito dall'uso di Notepad (o qualsiasi altro software) con permessi amministrativi rimuovendo manualmente le linee di header/footer dal file <code>attestation.b64</code> | ||
− | < | + | <u>Note sull'uso di Luna Network Attached HSM 7.x:</u> |
− | + | *processo non ancora testato | |
− | + | =====(''Per ogni nuovo certificato Code Signing su dispositivo FIPS già posseduto'') Sottomissione della richiesta e scarico del certificato da parte dell'utente===== | |
+ | Il richiedente che riceve la mail di invito dovrà: | ||
− | + | #Cliccare su "''Verify Email Address''" o copiare e incollare nel browser il link contenuto nella mail. Il link connette l'utente alla URL di sottomissione richiesta. La form di richiesta "Code Signing Enrollment" potrebbe risultare già parzialmente compilata. | |
+ | #Completare la compilazione della form facendo riferimento alla tabella sottostante. | ||
+ | #Accettare la "user agreement" e premere [''Submit''] | ||
− | <u> | + | Se la CSR e la key attestation sono valide, il richiedente riceverà una mail con il link per scaricare il certificato da Sectigo. Scaricare il certificato sul computer ed importarlo sul dispositivo HSM seguendo le istruzioni del Produttore. |
+ | {| class="wikitable" | ||
+ | |+ | ||
+ | !Campo | ||
+ | !Descrizione | ||
+ | |- | ||
+ | |Certificate email | ||
+ | |email del richiedente (!!! il dominio deve coincidere con uno di quelli delegati alla ORG di appartenenza !!!) | ||
+ | |- | ||
+ | |First name | ||
+ | |nome del richiedente | ||
+ | |- | ||
+ | |Last name | ||
+ | |cognome del richiedente | ||
+ | |- | ||
+ | |CSR | ||
+ | |CSR in formato PEM. Le linee di header/footer sono necessarie e <u>non</u> vanno rimosse | ||
+ | |- | ||
+ | |Key Attestation | ||
+ | |Contenuto del file '''attestation.b64''' creato al passo precedente. il File deve essere Base64 encoded. Le linee di header/footer <u>non</u> sono necessarie e <u>vanno rimosse</u> | ||
+ | |- | ||
+ | |HSM type | ||
+ | |Luna or YubiKey | ||
+ | |} | ||
− | + | ===Richiesta EV Code Signing Certificate=== | |
+ | Analogamente ai certificati ''Document Signing'', i certificati ''Code Signing EV'' devono essere ordinati su un token USB preconfigurato da Sectigo. | ||
− | + | I costi dei token USB non sono coperti dal servizio TCS e sono a carico del richiedente. | |
− | + | Per fare un ordine collegarsi a: https://www.sectigo.com/ssl-certificates-tls/code-signing e usare il codice sconto: '''3GE5YPN6T8''' | |
==Gestione Organizzazione== | ==Gestione Organizzazione== | ||
+ | ===Modifica della configurazione dell'Organizzazione=== | ||
+ | Dal menù principale selezionare ''Organizations''. Nella lista selezionare la checkbox relativo alla ''Organization'' da modificare. | ||
− | + | Si aprirà una finestra laterale composta dalle seguenti sezioni: ''Certificate Settings'', ''Domains'', ''Email Template, Access Control List, EV Details''. | |
− | |||
− | + | Per poter richiedere ''certificati IGTF (grid)'' è necessario modificare (scriv<u>endo un ticket a <[mailto:garr-ca@garr.it garr-ca@garr.it]></u>) il campo "Secondary Organization Name" prestando attenzione che contenga solo caratteri ASCII e che sia identico al campo O eventualmente usato in precedenza per i certificati grid con Digicert (in caso di dubbio consultare il portale Digicert per controllo). Dato che il subject dei certificati grid è usato come "username" è fondamentale che questo rimanga inalterato per non causare problemi di accesso alla grid per gli utenti. | |
− | + | Gli elementi contenuti in ''Certificate Settings'' permettono di personalizzare la configurazione ed in particolare nella sezione ''SSL Certificate'' è possibile configurare l'accesso via API (''Web API'') ed eventualmente configurare come obbligatorio un ''External Requester''. | |
− | + | La sezione ''Self Enrollment'' non è più parte della configurazione dell'Organizzazione. Vedere la sezione '''Richiesta certificati SSL tramite codice o autenticazione SAML'''. | |
===Aggiunta e configurazione Department=== | ===Aggiunta e configurazione Department=== | ||
− | <blockquote>Se necessario è possibile suddividere una Organizzazione in Dipartimenti con lo scopo di creare sotto-strutture che in autonomia possano gestire le richieste di certificati su determinati sotto-domini. Gli amministratori di tali sotto-strutture (DRAO) hanno poteri limitati al Dipartimento a cui sono assegnati e sui domini delegati a tale dipartimento. Per delegare un dominio ad un dipartimento seguire la sezione "'''Gestione domini'''"</blockquote>Dal menù principale | + | <blockquote>Se necessario è possibile suddividere una Organizzazione in Dipartimenti con lo scopo di creare sotto-strutture che in autonomia possano gestire le richieste di certificati su determinati sotto-domini. Gli amministratori di tali sotto-strutture (DRAO) hanno poteri limitati al Dipartimento a cui sono assegnati e sui domini delegati a tale dipartimento. Per delegare un dominio ad un dipartimento seguire la sezione "'''Gestione domini'''"</blockquote>Dal menù principale scegliere ''Organizations''. Nella tabella selezionare la checkbox relativa alla ''Organization'' su cui operare e premere il bottone [(+) Add Department]. |
Si aprirà una finestra pop-up (Departments) che permette di aggiungere nuovi dipartimenti, visualizzare e modificare i dipartimenti già creati. | Si aprirà una finestra pop-up (Departments) che permette di aggiungere nuovi dipartimenti, visualizzare e modificare i dipartimenti già creati. | ||
====Aggiungere un nuovo Dipartimento==== | ====Aggiungere un nuovo Dipartimento==== | ||
− | Premendo il bottone [Add] si aprirà un'ulteriore finestra di pop-up (Add New Department) composta | + | Premendo il bottone [(+) Add Department] si aprirà un'ulteriore finestra di pop-up (Add New Department) composta da due pagine: una prima parte con le generalità del Department e una seconda con le sezioni ''Client Certificate, SSL Certificate, Code Signing Certificate''. |
In ''General'' è possibile assegnare il nome al nuovo ''Department''. | In ''General'' è possibile assegnare il nome al nuovo ''Department''. | ||
− | In ''SSL Certificate'' è possibile configurare '' | + | In ''SSL Certificate'' è possibile configurare l'accesso via API (''Web API'') ed eventualmente configurare come obbligatorio un ''External Requester''. |
+ | |||
+ | La sezione ''Self Enrollment'' non è più parte della configurazione del ''Department''. Vedere la sezione '''Richiesta certificati SSL tramite codice o autenticazione SAML'''. | ||
In ''Client Certificate'' disabilitare la checkbox ''Allow Key Recovery by Master Administrators''. | In ''Client Certificate'' disabilitare la checkbox ''Allow Key Recovery by Master Administrators''. | ||
Riga 406: | Riga 669: | ||
In ''Code Signing Certificate'' è possibile abilitare tale tipo di certificato per questo Department se necessario. | In ''Code Signing Certificate'' è possibile abilitare tale tipo di certificato per questo Department se necessario. | ||
− | Premere [ | + | Premere [Save] per salvare la configurazione del nuovo Department. |
====Visualizzare e modificare i dipartimenti già creati==== | ====Visualizzare e modificare i dipartimenti già creati==== | ||
− | Selezionando | + | I ''Department'' già creati sono visualizzati. a partire dalla Organization, a cascata premendo il simbolo [>]. Selezionando la checkbox relativa al Department che si vuole visualizzare sarà possibile modificarlo, rimuoverlo definitivamente (simbolo del Cestino), aggiungere e consultare i domini delegati (Domains). |
− | Per la gestione dei domini associati ad un Department fare riferimento alla sezione Gestione Dominii. | + | Per la gestione dei domini associati ad un Department fare riferimento alla sezione '''Gestione Dominii'''. |
===Aggiunta e configurazione DRAO=== | ===Aggiunta e configurazione DRAO=== | ||
Riga 442: | Riga 705: | ||
===Reset della password=== | ===Reset della password=== | ||
Il reset della password di un account DRAO può essere fatto da qualsiasi DRAO dello stesso ''Department'' e dai RAO della stessa ''Organization''. Dal menù ''Admins'' selezionare il nome dell'amministratore da modificare, premere il bottone [Edit] e seguire il link ''Reset password''. La nuova password dovrà essere comunicata out-of-band al collega. | Il reset della password di un account DRAO può essere fatto da qualsiasi DRAO dello stesso ''Department'' e dai RAO della stessa ''Organization''. Dal menù ''Admins'' selezionare il nome dell'amministratore da modificare, premere il bottone [Edit] e seguire il link ''Reset password''. La nuova password dovrà essere comunicata out-of-band al collega. | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
==Configurazione SAML== | ==Configurazione SAML== | ||
Riga 552: | Riga 794: | ||
</syntaxhighlight>Per verificare il rilascio attributi al portale self-service SAML accedere, dopo l'autenticazione, a https://cert-manager.com/Shibboleth.sso/Session | </syntaxhighlight>Per verificare il rilascio attributi al portale self-service SAML accedere, dopo l'autenticazione, a https://cert-manager.com/Shibboleth.sso/Session | ||
− | ==ACME | + | ==ACME e gestione automatizzata dei certificati SSL== |
− | Il protocollo ACME, ''Automated Certificate Management Environment'', è uno standard IETF (RFC 8555) per la gestione automatizzata dei certificati X.509. | + | ''Tempo di Lettura: '''20 minuti'''''<blockquote>'''<u>Attenzione:</u>''' a partire dalla data del 18 Marzo 2022, in cui è avvenuta la '''migrazione del portale SCM''', gli account ACME creati in precedenza non sono più funzionanti e pertanto è necessario crearne di nuovi. </blockquote>Il protocollo ACME, ''Automated Certificate Management Environment'', è uno standard IETF (RFC 8555) per la gestione automatizzata dei certificati X.509. |
Il protocollo ACME è stato implementato per la prima volta da [https://letsencrypt.org Let's Encrypt], la Certification Authority libera e gratuita gestita dal [https://www.abetterinternet.org/ Internet Security Research Group (ISRG)]. E' bene ricordare che se da una parte Let's Encrypt fornisce un servizio formidabile, dall'altra supporta solo i certificati di tipo DV. | Il protocollo ACME è stato implementato per la prima volta da [https://letsencrypt.org Let's Encrypt], la Certification Authority libera e gratuita gestita dal [https://www.abetterinternet.org/ Internet Security Research Group (ISRG)]. E' bene ricordare che se da una parte Let's Encrypt fornisce un servizio formidabile, dall'altra supporta solo i certificati di tipo DV. | ||
Riga 568: | Riga 810: | ||
*Supporto ACME in Sectigo: vedi il capitolo "Using the Sectigo ACME Service" della guida ''SCM - Sectigo Certificate Manager Administrator's Guide/'' | *Supporto ACME in Sectigo: vedi il capitolo "Using the Sectigo ACME Service" della guida ''SCM - Sectigo Certificate Manager Administrator's Guide/'' | ||
− | === | + | ===Installazione di certbot=== |
− | Per | + | Per l'installazione di certbot è caldamente consigliato seguire sempre le istruzioni ufficiali disponibili su https://certbot.eff.org. |
+ | Qualora nel menù a tendina "system" non sia presente il S.O. in uso consigliamo di eseguire l'installazione via pip. | ||
+ | Riportiamo qui le istruzioni per l'installazione di certbot via pip, per maggiori informazioni vi consigliamo di consultare le istruzioni ufficiali e più recenti su https://certbot.eff.org. | ||
+ | |||
+ | *'''SSH into the server''' | ||
+ | |||
+ | Tutti i comandi che seguono devono essere eseguiti da root o con sudo. | ||
+ | Accedere con ssh al server in cui gira il server HTTP oppure nel sistema in cui si vuole generare il certificato. | ||
+ | |||
+ | *'''Install system dependencies''' | ||
+ | |||
+ | Le dipendenze di sistema includono generalmente Python 3.6+, il modulo venv e il plug-in Augeas per Apache. | ||
+ | |||
+ | In caso di problemi nell'installazione dei moduli di crittografia potrebbe essere necessario installare dipendenze addizionali. Per maggiori informazioni vedere [https://cryptography.io/en/latest/installation.html#building-cryptography-on-linux cryptography project's site]. | ||
+ | |||
+ | I comandi per installare le dipendenze sulla macchina sono i seguenti: | ||
+ | |||
+ | Per distribuzioni APT-based(e.g. Debian, Ubuntu ...): | ||
+ | sudo apt update | ||
+ | sudo apt install python3 python3-venv libaugeas0 | ||
+ | |||
+ | |||
+ | Per distribuzioni RPM-based (e.g. Fedora, CentOS ...): | ||
+ | sudo dnf install python3 augeas-libs | ||
+ | |||
+ | *'''Remove certbot-auto and any Certbot OS packages''' | ||
+ | |||
+ | Se sono presenti pacchetti Certbot installati utilizzando un gestore di pacchetti del sistema operativo come apt, dnf o yum, è necessario rimuoverli prima di installare lo snap Certbot per garantire che quando si esegue il comando certbot venga utilizzato lo snap anziché l'installazione dal pacchetto del sistema operativo manager. Il comando esatto per eseguire questa operazione dipende dal sistema operativo, ma sono esempi comuni <code>sudo apt-get remove certbot</code>, <code>sudo dnf remove certbot</code>, o <code>sudo yum remove certbot</code>. | ||
+ | |||
+ | *'''Set up a Python virtual environment''' | ||
+ | |||
+ | Eseguire le seguenti istruzioni sulla riga di comando sulla macchina per configurare un ambiente virtuale. | ||
+ | sudo python3 -m venv /opt/certbot/ | ||
+ | sudo /opt/certbot/bin/pip install --upgrade pip | ||
− | + | *'''Install Certbot''' | |
− | + | Eseguire questo comando sulla riga di comando sulla macchina per installare Certbot. | |
− | + | sudo /opt/certbot/bin/pip install certbot certbot-apache | |
− | |||
− | + | *'''Prepare the Certbot command''' | |
− | + | Eseguire le seguenti istruzioni sulla riga di comando sulla macchina per garantire che il comando certbot possa essere eseguito. | |
− | + | sudo ln -s /opt/certbot/bin/certbot /usr/bin/certbot | |
− | |||
− | |||
− | + | *'''Set up automatic renewal''' | |
− | * | + | Eseguire la riga seguente, che aggiungerà un processo cron al crontab predefinito. |
− | * | + | echo "0 0,12 * * * root /opt/certbot/bin/python -c 'import random; import time; time.sleep(random.random() * 3600)' && sudo certbot renew -q" | sudo tee -a /etc/crontab > /dev/null |
− | *' | ||
− | *' | ||
− | + | *'''[Monthly] Upgrade certbot''' | |
− | + | È importante fare l'upgrade periodico di Certbot per mantenerlo aggiornato. Per fare ciò, eseguire il comando seguente sulla riga di comando della macchina. | |
− | + | sudo /opt/certbot/bin/pip install --upgrade certbot certbot-apache | |
− | + | Se questo passaggio genera errori, eseguire sudo <code>rm -rf /opt/certbot</code> e ripetere tutte le istruzioni di installazione dall'inizio. | |
− | |||
− | + | ===(Sectigo) Creazione account ACME in SCM=== | |
+ | Per poter iniziare ad utilizzare ACME con Sectigo è necessario creare uno o più account ACME per la propria organizzazione. | ||
− | + | Accedere a SCM con un account RAO (o DRAO, <u>assicurandosi che la delega dei domini al ''Department'' sia stata preventivamente effettuata da un RAO</u>) e dal menù principale selezionare ''Enrollment > ACME''. <blockquote>''<u>Workaround</u>'': se gli endpoint per ACME non fossero disponibili agire nella sezione '''Filter''' eseguendo i seguenti passaggi: | |
− | |||
− | <blockquote>''' | ||
− | + | #dal menù Add Filter → Select Type | |
+ | #dal menù Type → scegliere Public ACME CA | ||
+ | </blockquote><u>Nota importante</u>: l'endpoint DV, anche se presente nell'elenco, non è compreso nel contratto TCS e non è utilizzabile. | ||
− | + | Dall'elenco di endpoint (in seguito riferiti come ''ACME URL'') selezionare uno tra <code><nowiki>https://acme.sectigo.com/v2/OV</nowiki></code> e <code><nowiki>https://acme.sectigo.com/v2/GEANTOV</nowiki></code> se volete creare un account ACME per certificati OV, o uno tra <code><nowiki>https://acme.sectigo.com/v2/EV</nowiki></code> e <code><nowiki>https://acme.sectigo.com/v2/GEANTEV</nowiki></code> per certificati EV e poi premere il bottone [Accounts]. Nella finestra che si aprirà premere il bottone verde [+] per aggiungere un nuovo account. Nella finestra di creazione dell'account è necessario: | |
− | |||
− | + | *inserire il nome del account nel campo ''Name.'' | |
+ | *scegliere la ''Organization'' dal menù a tendina (nella maggior parte dei casi ci sarà una sola organizzazione e tutto sarà già selezionato). | ||
+ | *scegliere eventualmente il ''Department''. | ||
+ | *nella sezione ''DOMAINS'' scegliere con il (+) i dominii per cui abilitare questo account e premere il tasto [Save]. La lista dei domini è modificabile anche in seguito, vedere più sotto. <u>Includere sempre anche il dominio nella versione *. altrimenti l'account non sarà in grado di funzionare correttamente</u> (esempio <code>subdomain.domain.org</code> e <code>*.subdomain.domain.org</code> o<code>domain.org</code> e <code>*.domain.org</code> se si vuole chiedere un certificato per <code>www.subdomain.domain.org</code>). | ||
− | + | L'account verrà creato immediatamente e verranno visualizzati a video i dati del nuovo che dovranno essere copiati: | |
− | + | *''ACME URL'' | |
+ | *''Account ID'' | ||
+ | *''Key ID'' | ||
+ | *''HMAC Key'' | ||
− | + | <blockquote>'''IMPORTANTE''' ''Key ID'' e ''HMAC Key'' sono le credenziali dell'account ACME appena creato e dalla release SCM 22.1 il portale Sectigo SCM le mostrerà nella sezione ''Details.'' Questo significa che i parametri possono essere riutilizzati per registrare l'account ACME su più server.</blockquote>Una volta creato l'account e visualizzate le credenziali, l'interfaccia ritornerà sull'elenco degli account ACME disponibili per l'organizzazione (dipartimento nel caso di un DRAO), dove l'account appena creato sarà inizialmente in stato ''pending''. <u>Non c'è da preoccuparsi: l'account è già operativo e può essere già utilizzato.</u> | |
− | + | L'account creato è di tipo EAB (External Account Binding), ed i certificati relativi saranno classificati in SCM con status ''External''. Inoltre le Certification Authority intermedie per i certificati emessi tramite ACME sono diverse da quelle utilizzate per i certificati emessi tramite SCM o tramite le API di Sectigo. Ad esempio per i certificati di tipo OV avremo la CA intermedia ''Sectigo RSA Organization Validation Secure Server CA'' invece che ''GÉANT OV RSA CA 4''. Ovviamente dal punto di vista funzionale non c'è alcuna differenza. | |
− | |||
− | + | <u>Per modificare l'elenco dei domini associati ad un account ACME</u> selezionare dall'elenco degli account quello desiderato e selezionare il bottone [Edit]. Nella finestra successiva sarà possibile agire nella sezione ''DOMAINS'' e modificare i domini con (+). | |
− | + | <u>Per visualizzare l'elenco dei ''Client'' su cui è stato registrato l'account ACME</u> selezionare dall'elenco degli account quello desiderato e selezionare il bottone [Clients]. Nella finestra successiva sarà possibile vedere le informazioni sui ''Client'' (bottone [Details]) e rimuoverli singolarmente. | |
− | + | ===(Sectigo) Registrazione account ACME in certbot, emissione, rinnovo automatico e revoca dei certificati=== | |
− | ===Registrazione account | + | ====Registrazione in certbot di un account creato in SCM==== |
Tutti i comandi che seguono devono essere eseguiti da root o con sudo. | Tutti i comandi che seguono devono essere eseguiti da root o con sudo. | ||
Prima di cominciare a gestire i certificati è necessario registrare il nostro account Sectigo ACME con il comando che segue: | Prima di cominciare a gestire i certificati è necessario registrare il nostro account Sectigo ACME con il comando che segue: | ||
− | certbot register --email < | + | certbot register --email <EMAIL> --server <ACME URL> --eab-kid <KEY ID> --eab-hmac-key <HMAC KEY> |
− | Sostituire <KEY ID> | + | Sostituire <KEY ID>, <HMAC KEY> e <ACME URL> con i corrispondenti valori che vi si siete segnati durante la creazione dell'account ACME su SCM. |
Il processo di registrazione comporta l'accettazione dei Terms of Service; vi verrà inoltre richiesto se volete condividere la mail con la Electronic Frontier Foundation. | Il processo di registrazione comporta l'accettazione dei Terms of Service; vi verrà inoltre richiesto se volete condividere la mail con la Electronic Frontier Foundation. | ||
− | Il risultato sarà la creazione dell'account e della relativa chiave nella directory <code>/etc/letsencrypt/accounts</code>.<blockquote>'''IMPORTANTE''' | + | Il risultato sarà la creazione dell'account e della relativa chiave nella directory <code>/etc/letsencrypt/accounts</code>.<blockquote>'''IMPORTANTE''' Non è possibile registrare due account ACME di Sectigo sullo stesso client. E' possibile avere più account ACME registrati sullo stesso client a patto che siano di due Certification Autority differenti. Prima di registrare un nuovo account ACME della stessa CA occorre rimuovere il precedente.</blockquote> |
====Validazione dei dominii==== | ====Validazione dei dominii==== | ||
− | certbot supporta anche la validazione dei dominii tramite ''.well-known'' path, ma | + | certbot supporta anche la validazione dei dominii tramite ''.well-known'' path, ma dato che gli account ACME/Sectigo sono legati ad una ben definita ORG i cui dominii sono già stati creati e validati su SCM, non è richiesto fare alcuna validazione dei domini via certbot. |
+ | |||
+ | Assicurarsi che i domini associati all'account ACME siano validati ("Validated" con etichetta verde). La procedura è quella indicata più sopra "Gestione Dominii" -> "Validazione dominio" e la rivalidazione deve avvenire annualmente. ACME non può rilasciare certificati per domini non validati. | ||
− | ==== | + | ====Emissione dei certificati==== |
certbot permette di creare ed installare automaticamente i certificati dei virtual host presenti e correttamente configurati sul nostro server web, o semplicemente di creare i certificati senza installazione automatica. | certbot permette di creare ed installare automaticamente i certificati dei virtual host presenti e correttamente configurati sul nostro server web, o semplicemente di creare i certificati senza installazione automatica. | ||
− | Con il comando <code>run</code> si creano ed installano chiave e certificato per il virtualhost | + | Con il comando <code>run</code> si creano ed installano chiave e certificato per il virtualhost <code><FQDN-certificato></code> (sostituire <code><ACME URL></code> con il corrispondente valore presente nell'account ACME su SCM): |
− | certbot run --apache --email | + | certbot run --apache --email <EMAIL> --server <ACME URL> --domain <FQDN-certificato> --key-type rsa --rsa-key-size 3072 --cert-name <FRIENDLY-NAME> |
+ | oppure per chiavi ECC | ||
+ | certbot run --apache --email <EMAIL> --server <ACME URL> --domain <FQDN-certificato> --key-type ecdsa --elliptic-curve secp384r1 --cert-name <FRIENDLY-NAME> | ||
Le modalità di installazione possono variare a seconda delle distribuzioni, ma in generale certbot, una volta creati chiave e certificato, tenterà di individuare la configurazione del virtualhost apache corrispondente e di modificarla per farla puntare al certificato ed alla chiave appena creati. | Le modalità di installazione possono variare a seconda delle distribuzioni, ma in generale certbot, una volta creati chiave e certificato, tenterà di individuare la configurazione del virtualhost apache corrispondente e di modificarla per farla puntare al certificato ed alla chiave appena creati. | ||
− | Per limitarsi alla <u>sola creazione del certificato</u> e della relativa in formato PEM, utilizzare invece il comando <code>certonly</code> con l'opzione <code>--standalone</code>: | + | Per limitarsi alla <u>sola creazione del certificato</u> e della relativa in formato PEM, utilizzare invece il comando <code>certonly</code> con l'opzione <code>--standalone</code> (sostituire <code><ACME URL></code> con il corrispondente valore presente nell'account ACME su SCM): |
+ | |||
+ | certbot certonly --standalone --email <EMAIL> --server <ACME URL> --domain <FQDN-certificato> --key-type rsa --rsa-key-size 3072 --cert-name <FRIENDLY-NAME> | ||
− | + | oppure per chiavi ECC | |
− | Per richiedere un <u>certificato con SAN multipli</u>, quindi per più nomi di dominio, ripetere l'opzione <code>--domain DOMINIO</code> o utilizzare una lista di nomi di dominio separata da virgola, ma senza spazi, come da esempio: | + | certbot certonly --standalone --email <EMAIL> --server <ACME URL> --domain <FQDN-certificato> --key-type ecdsa --elliptic-curve secp384r1 --cert-name <FRIENDLY-NAME> |
− | certbot certonly -- | + | |
+ | Per richiedere un <u>certificato con SAN multipli</u>, quindi per più nomi di dominio, ripetere l'opzione <code>--domain DOMINIO</code> o utilizzare una lista di nomi di dominio separata da virgola, ma senza spazi, come da esempio (sostituire <code><ACME URL></code> con il corrispondente valore presente nell'account ACME su SCM): | ||
+ | certbot certonly --standalone --email <EMAIL> --server <ACME URL> --domain <FQDN-certificato1>,<FQDN-certificato2>,<FQDN-certificato2> --key-type rsa --rsa-key-size 3072 --cert-name <FRIENDLY-NAME> | ||
+ | oppure per chiavi ECC | ||
+ | certbot certonly --standalone --email <EMAIL> --server <ACME URL> --domain <FQDN-certificato1>,<FQDN-certificato2>,<FQDN-certificato2> --key-type ecdsa --elliptic-curve secp384r1 --cert-name <FRIENDLY-NAME> | ||
Alcune opzioni utili in fase di creazione dei certificati: | Alcune opzioni utili in fase di creazione dei certificati: | ||
− | *<code>--quiet</code> silenzia il comando, utile per automation | + | *<code>--quiet</code> silenzia il comando, utile per automation |
+ | |||
+ | *<code>--non-intereactive</code> utile per automation, ma necessita di ulteriori opzioni | ||
+ | *<code>--key-type</code> permette di scegliere il tipo di chiave {rsa,ecdsa} | ||
− | *<code>-- | + | *<code>--rsa-key-size BITS</code> per specificare la grandezza della chiave RSA in bits, il default è 2048 |
+ | *<code>--elliptic-curve N</code> per specificare la lunghezza della chiave ECC in bits, il default è secp256r1 | ||
− | + | Tutti i certificati creati vengono salvati in <code>/etc/letsencrypt/archive/<DOMAIN></code> e collegati in <code>/etc/letsencrypt/live/<DOMAIN></code> se attivi. Inoltre le chiavi private sono salvate come <code>privkey.pem</code> . | |
− | + | '''<u>Importante</u>''': assicurarsi di configurare il rinnovo automatico del certificato. Molti dei pacchetti di installazione di certbot includono già una configurazione di base per il rinnovo dei certificati via cron. In generale conviene sempre fare riferimento alle "'''Certbot instructions / Set up automatic renewal'''" presenti nel sito https://certbot.eff.org/instructions relative al software e al sistema prescelto. | |
====Revoca dei certificati==== | ====Revoca dei certificati==== | ||
− | Per revocare i certificati emessi utilizzare il comando <code>revoke</code>: | + | Per revocare i certificati emessi utilizzare il comando <code>revoke</code>(sostituire <code><ACME URL></code> con il corrispondente valore presente nell'account ACME su SCM): |
− | certbot revoke --email | + | certbot revoke --email <EMAIL> --server <ACME URL> --cert-name <FQDN-certificato> |
Nel caso di certificati per più nomi di dominio, basterà specificare uno dei nomi validi. Inoltre tramite l'opzione <code>--cert-path</code> è possibile utilizzare il percorso del certificato al posto del nome di dominio: | Nel caso di certificati per più nomi di dominio, basterà specificare uno dei nomi validi. Inoltre tramite l'opzione <code>--cert-path</code> è possibile utilizzare il percorso del certificato al posto del nome di dominio: | ||
− | certbot revoke --email | + | certbot revoke --email <EMAIL> --server <ACME URL> --cert-path /etc/letsencrypt/live/<FQDN-certificato>/cert.pem |
− | ====Rinnovo dei certificati==== | + | ====Rinnovo automatico e forzato dei certificati==== |
La semplicità con cui è possibile rinnovare i certificati è molto probabilmente il maggior punto di forza di ACME e certbot. | La semplicità con cui è possibile rinnovare i certificati è molto probabilmente il maggior punto di forza di ACME e certbot. | ||
Riga 701: | Riga 989: | ||
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin | PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin | ||
0 */12 * * * root test -x /usr/bin/certbot -a \! -d /run/systemd/system && perl -e 'sleep int(rand(43200))' && certbot -q renew | 0 */12 * * * root test -x /usr/bin/certbot -a \! -d /run/systemd/system && perl -e 'sleep int(rand(43200))' && certbot -q renew | ||
− | E' anche possibile forzare il rinnovo del certificato di un solo dominio utilizzando il comando certonly e le opportune opzioni. Ad esempio per forzare il rinnovo del nome di dominio | + | E' anche possibile forzare il rinnovo del certificato di un solo dominio utilizzando il comando certonly e le opportune opzioni. Ad esempio per forzare il rinnovo del nome di dominio <code><FQDN-certificato1></code>, riutilizzando la chiave esistente (sostituire <code><ACME URL></code> con il corrispondente valore presente nell'account ACME su SCM): |
− | certbot certonly --standalone --force-renewal --reuse-key --agree-tos --email | + | certbot certonly --standalone --force-renewal --reuse-key --agree-tos --email <EMAIL> --server <ACME URL> --domain <FQDN-certificato1> |
− | ==== | + | ====Utilizzo di un account ACME su più server==== |
− | + | Per utilizzare certbot su più server avete le seguenti opzioni: | |
+ | |||
+ | #creare un account ACME su SCM per ogni server da abilitare e registrarlo seguendo le istruzioni "Registrazione account ACME e uso di certbot". | ||
+ | #registrare un account ACME esistente su più server seguendo le istruzioni "Registrazione account ACME e uso di certbot". | ||
+ | #copiare le chiavi di uno degli account ACME già registrati in ogni server che si desidera abilitare trasferendo tutto il contenuto della directory <code>/etc/letsencrypt/accounts</code> presente sul primo server su cui è stata effettuata la registrazione. | ||
+ | |||
+ | La seconda opzione dovrebbe essere la più conveniente nella maggior parte delle situazioni perché permette di tener traccia dei client su cui è stata effettuata la registrazione dell'account ACME (vedere l'apposita sezione in SCM). | ||
+ | |||
+ | ===(Let's encrypt) emissione, rinnovo automatico e revoca dei certificati=== | ||
+ | |||
+ | Tutti i comandi devono essere eseguiti da root o con sudo accedendo con ssh al server in cui gira il server HTTP. | ||
+ | |||
+ | Per l'installazione di certbot e la richiesta di certificati con Let's encrypt è caldamente consigliato '''seguire sempre le istruzioni ufficiali''' disponibili su https://certbot.eff.org. Qualora nel menù a tendina "system" non sia presente il S.O. in uso consigliamo di eseguire l'installazione via '''pip'''. Per maggiori informazioni vi consigliamo di consultare le istruzioni ufficiali e più recenti su <nowiki>https://certbot.eff.org</nowiki>. | ||
+ | |||
+ | Esempio di link per la combinazione "Apache" + "pip": https://certbot.eff.org/instructions?ws=apache&os=pip | ||
+ | |||
+ | <u>IMPORTANTE:</u> seguire esattamente tutti i passi indicati dalla guida di certbot. | ||
+ | |||
+ | Ogni istanza del client certbot permette la registrazione di un solo account per Certification Authority ma anche la registrazione di un secondo account se proveniente da una Certification Authority diversa. | ||
+ | |||
+ | E' dunque possibile registrare contemporaneamente nella stessa istanza di certbot sia un account Sectigo che uno Let's encrypt. | ||
+ | |||
+ | ====Quali account sono registrati in un'istanza di certbot==== | ||
+ | |||
+ | Tramite i seguenti comandi si può scoprire se un'instanza di certbot ha già degli account associati: | ||
+ | |||
+ | *<code><nowiki>certbot show_account</nowiki></code> '''(Let’s encrypt)''' | ||
+ | *<code><nowiki>certbot show_account --server https://acme.sectigo.com/v2/OV</nowiki></code> '''(Sectigo OV)''' | ||
+ | *<code><nowiki>certbot show_account --server https://acme.sectigo.com/v2/GEANTOV</nowiki></code> '''(Sectigo GEANTOV)''' | ||
+ | |||
+ | ====Il web server deve essere raggiungibile==== | ||
+ | Prima di poter richiedere un certificato con Let's encrypt assicurarsi che il fqdn del server sia raggiungibile via web. | ||
+ | |||
+ | In caso negativo non sarà possibile procedere con la richiesta di certificato usando le istruzioni seguenti. Fare riferimento alla documentazione di certbot per tutte le altre casistiche. | ||
+ | |||
+ | ====Richiedere e installare in automatico un certificato==== | ||
+ | Lanciare il seguente comando per richiedere un certificato ed installarlo su Apache: | ||
+ | sudo certbot --apache | ||
+ | o su Nginx: | ||
+ | sudo certbot --nginx | ||
+ | |||
+ | ====Richiedere un certificato senza installazione automatica==== | ||
+ | Per richiedere un certificato in maniera più conservativa senza installazione su Apache: | ||
+ | sudo certbot certonly --apache | ||
+ | o per Nginx | ||
+ | sudo certbot certonly --nginx | ||
+ | Installare manualmente il certificato tramite i file di configurazione del server web. | ||
+ | |||
+ | ====Consultare la lista dei certificati gestiti dal client certbot==== | ||
+ | Lanciare il comando: | ||
+ | certbot certificates | ||
+ | oppure consultare il contenuto delle cartelle <code>/etc/letsencrypt/{live,archive}</code> | ||
+ | |||
+ | ====Revocare un certificato==== | ||
+ | Con certbot esistono due modalità per revocare un certificato: tramite opzione <code>cert-name</code> e indicando direttamente il percorso del file. | ||
+ | certbot revoke --cert-name example.com | ||
+ | |||
+ | certbot revoke --cert-path /etc/letsencrypt/live/example.com/cert.pem | ||
+ | Completata la revoca certbot chiederà se si desidera cancellare i certificati appena revocati. Se i certificati revocati non sono stati cancellati certbot proverà a rinnovarli durante il prossimo rinnovo automatico. | ||
+ | |||
+ | ====Consultazione certificati==== | ||
+ | Per consultare la situazione dei certificati emessi accedere al sito: | ||
+ | https://crt.sh/ | ||
+ | seguendo le istruzioni di ricerca fornite dal sito stesso. | ||
+ | |||
− | |||
− | |||
− | |||
<br /> | <br /> |
Versione attuale delle 15:33, 12 lug 2024
Indice
- 1 GARR Certification Service
- 2 Registration Authority Officer
- 3 Gestione Dominii
- 4 Emissione Certificati
- 4.1 Richiesta SSL Certificate (What is a CSR?)
- 4.2 Approvazione di Richieste per SSL Certificate
- 4.3 Installazione SSL Certificate
- 4.4 Consultazione dei certificati SSL
- 4.5 Richiesta Client Certificate via SCM con invito (solo per
GÉANT IGTF-Classic-Robot Email"GÉANT Organisation Automated Authentication") - 4.6 Richiesta Client Certificate con portale self-service via SAML
- 4.7 Gestione dei Certificati Personali
- 4.8 Richiesta Document Signing Certificate
- 4.9 Richiesta Code Signing Certificate
- 4.9.1 Descrizione del servizio a partire da maggio 2023
- 4.9.2 Istruzioni a partire da Maggio 2023
- 4.9.2.1 (Solo la prima volta) Creazione da parte del RAO di un Account per certificati su dispositivo FIPS già posseduto
- 4.9.2.2 (Per ogni nuovo certificato Code Signing su dispositivo FIPS già posseduto) Creazione di un invito da parte del RAO
- 4.9.2.3 (Per ogni nuovo certificato Code Signing su dispositivo FIPS già posseduto) Creazione della CSR e della Key Attestation da parte dell'utente
- 4.9.2.4 (Per ogni nuovo certificato Code Signing su dispositivo FIPS già posseduto) Sottomissione della richiesta e scarico del certificato da parte dell'utente
- 4.10 Richiesta EV Code Signing Certificate
- 5 Gestione Organizzazione
- 6 Configurazione SAML
- 7 ACME e gestione automatizzata dei certificati SSL
- 7.1 Installazione di certbot
- 7.2 (Sectigo) Creazione account ACME in SCM
- 7.3 (Sectigo) Registrazione account ACME in certbot, emissione, rinnovo automatico e revoca dei certificati
- 7.4 (Let's encrypt) emissione, rinnovo automatico e revoca dei certificati
- 7.4.1 Quali account sono registrati in un'istanza di certbot
- 7.4.2 Il web server deve essere raggiungibile
- 7.4.3 Richiedere e installare in automatico un certificato
- 7.4.4 Richiedere un certificato senza installazione automatica
- 7.4.5 Consultare la lista dei certificati gestiti dal client certbot
- 7.4.6 Revocare un certificato
- 7.4.7 Consultazione certificati
GARR Certification Service
GARR CS (Certification Service) gestisce il servizio GÉANT TCS (Trusted Certificate Service) per la comunità della ricerca italiana.
Adesione
Per la procedura di adesione scaricare il file zip contenente moduli e istruzioni da GARR CS Adesione
Prima della compilazione dei moduli di adesione siete pregati di considerare che è necessario indicare il "full legal name" del vostro Ente affinché Sectigo possa procedere con la validazione della Organizzazione secondo le regole specificate qui di seguito.
Validazione dell'Organizzazione
Per poter emettere certificati (SSL, client, code signing) un'Organizzazione deve essere stata validata dalla CA.
Il processo di validazione di un'Organizzazione, svolto dalla CA, avviene inizialmente nel momento dell'adesione e successivamente con cadenza annuale. Dal 1 settembre 2023 le regole di validazione dell'Organizzazione (OV) sono cambiate per adeguarsi alle Baseline Requirements per l'emissione dei certificati S/MIME e sono diventate molto più complesse rispetto al passato. Le regole, stabilite dal CA/B Forum, sono disponbiili in questo documento: https://cabforum.org/wp-content/uploads/CA-Browser-Forum-SMIMEBR-1.0.0.pdf
Sectigo ha diffuso un video webinar di approfondimento sulle nuove Baseline Requirements per S/MIME: https://www.youtube.com/watch?v=ewsbwSDOd6k
Il punto fondamentale delle nuove regole è: "3.2.3.2.1 Verification of name, address, and unique identifier" e riguarda la documentazione da presentare per provare alla CA l'esistenza legale della propria Organizzazione:
- A government agency in the jurisdiction of the Legal Entity’s creation, existence, or recognition;
- A Legal Entity Identifier (LEI) data reference;
- A site visit by the CA or a third party who is acting as an agent for the CA; or
- An Attestation which includes a copy of supporting documentation used to establish the Applicant’s legal existence, such as a certificate of registration, articles of incorporation, operating agreement, statute, or regulatory act.
Per esperienza recente, abbiamo visto che vengono accettati i seguenti link a siti web e documenti:
- Indicepa: banca dati di libera consultazione (https://indicepa.gov.it/ipa-portale/)
- Registro Imprese (https://www.registroimprese.it/) e visure camerali
- VIES VAT number validation (https://ec.europa.eu/taxation_customs/vies/#/vat-validation)
- Durc online (https://www.inail.it/cs/internet/attivita/assicurazione/verificare-la-regolarita-contributiva-durc-online.html)
- essere indicizzati in un sito governativo italiano o europeo (Ministero, Camera, Senato, Esteri)
- Statuto dell'Organizzazione
- Riferimenti esatti del "full legal name" e indirizzo postale presenti in Gazzetta Ufficiale
- Legal Entity Identifier (LEI) (https://www.gleif.org/en/about-lei/introducing-the-legal-entity-identifier-lei)
Per esperienza, quando la CA non riesce a verificare l'esistenza legale di un'Organizzazione ci contatta chiedendo quanto segue:
Oggetto: Legal existence pending
As per the revised validation policy we are required to verify the legal existence of all organizations prior to issuing certificates. We are in the process of validating the details of your organization as part of our certificate issuance process. However, we are unable to locate your organization's registration details in our existing records. Kindly provide an official government URL to confirm your organization formation or Act that confirms your organization's legal status and registration information. Once we have verified the information, we will proceed with your order issuance.
Il servizio GARR CS contatterà l'Organizzazione non ancora validata per richiedere la prova di esistenza legale secondo una delle modalità indicate sopra. La mancata collaborazione nel procurare la documentazione necessaria alla validazione comporterà la mancata emissione dei certificati.
I tempi necessari alla validazione sono molto incerti e dipendono dalla CA: si può andare da un minimo di 2 gg fino a 4 settimane.
La velocità di validazione dipende molto dalla qualità dei documenti e riferimenti presentati. Documenti che non rispettano i requisiti o che sono molto vecchi potrebbero essere rifiutati dalla CA.
Supporto
Per richieste di adesione, supporto, problemi tecnici e gestione degli account Admin scrivete a <garr-ca@garr.it>.
Per aprire un Ticket verso Sectigo: https://sectigo.com/support-ticket
Mailing list TCS-GARR
Per domande generali sull'uso della piattaforma, sui tipi di certificati, la loro creazione ed il loro uso utilizzate la mailing list <tcs@garr.it>.
L'iscrizione alla lista è a cura di GARR CS ed è riservata ai Registration Authority Officers e i Department Registration Authority Officers nominati da ogni organizzazione.
La lista viene utilizzata da GARR CS per inviare annunci sullo stato del servizio e per lo scambio di informazioni tra i partecipanti.
I partecipanti alla lista sono liberi di utilizzare e redistribuire le informazioni ricevute, ma non di rivelare l'identità o l'affiliazione della fonte delle informazioni senza prima aver ottenuto un permesso specifico dalla fonte stessa.
Link utili
- Per scaricare le root intermediate di GÉANT (in uso dal 1 settembre 2023) è disponibile il seguente repository: https://wiki.geant.org/display/TCSNT/TCS+Trust+Anchors+and+Intermediates
- Per scaricare le root intermediate di GÉANT (in uso fino al 1 settembre 2023) è disponibile il seguente repository: https://crt.sh/?CAName=%25GEANT+Vereniging%25
- Per conoscere i metodi di validazione DCV alternativi è disponile il seguente articolo di Sectigo: https://www.sectigo.com/resource-library/domain-control-validation-dcv-methods-how-to-choose
- Come generare una richiesta CSR con OpenSSL: https://www.sectigo.com/knowledge-base/detail/CSR-Generation-Using-OpenSSL-Apache-w-mod-ssl-NGINX-OS-X/kA01N000000zGKQ
- Come generare una richiesta CSR con OpenSSL per IIS (in formato .pdf by RAO@UNITO): File:CertificatiWindowsIIS.pdf
- Come generare una richiesta CSR con MMC (Microsoft): https://www.entrustdatacard.com/knowledgebase/ssl/how-to-generate-certificate-signing-request-using-microsoft-management-console-mmc-on-windows-2012
- Come generare una richiesta CSR in Windows con certreq (command shell): https://www.sectigo.com/knowledge-base/detail/CSR-Generation-Using-certreq-Windows-1527076090647/kA01N000000zFM0
- Come creare un file PKCS#7, (.p7b) a partire dal formato .crt /.cer in Windows: https://www.sectigo.com/knowledge-base/detail/How-to-create-a-PKCS-7-p7b-formats-from-crt-or-cer-certificates-on-Wind ows/kA03l00000117Se
- Internal domain/server names (Reserved IP Addresses): https://www.sectigo.com/knowledge-base/detail/Internal-domain-server-names-Reserved-IP-Addresses-1527076114398/kA01N000000zFUB
Documentazione Sectigo
La documentazione Sectigo è disponibile in https://support.sectigo.com/Com_KnowledgeProductPage?c=Sectigo_Certificate_Manager_SCM
In particolare:
- SCM - Sectigo® Certificate Manager Quick Start Guide è una guida rapida per iniziare a lavorare con il portale SCM
- SCM - Sectigo Certificate Manager Administrator's Guide è la guida completa del portale SCM per Amministratori
- SCM - Sectigo Certificate Manager REST API è la guida per interfacciarsi al sistema con le API REST
GÉANT Wiki TCS 2020 FAQ: https://wiki.geant.org/display/TCSNT/TCS+2020+FAQ
Configurazione iniziale (Quickstart)
Se stai accedendo per la prima volta al nuovo servizio TCS (Sectigo Limited) è necessario leggere con attenzione le informazioni che seguono.
Definizioni
SCM = Sectigo Certificate Manager, il nome del portale per la gestione dei certificati x.509
MRAO = Master Registration Authority Officer, ruolo amministrativo di alto livello riservato ad ogni NREN che ha sottoscritto il contratto GÉANT TCS. Per GARR il ruolo è affidato ai membri del Servizio GARR CS.
RAO = Registration Authority Officer, ruolo amministrativo a livello di Organizzazione che permette la gestione di dipartimenti, domini, certificati e ruoli amministrativi afferenti a tale Organizzazione
DRAO = Department Registration Authority Officer, ruolo amministrativo a livello di Dipartimento che permette la gestione di domini, certificati e ruoli amministrativi afferenti a tale Dipartimento. (opzionale)
Primi passi
- E' necessario inizializzare una chiave di cifratura per ogni Organizzazione e Dipartimento creato nel Portale SCM. Si tratta di una chiave Escrow (https://it.wikipedia.org/wiki/Key_escrow) e senza un'inizializzazione non sarà possibile richiedere certificati personali tramite la GUI del Portale stesso. Per procedere scegliere dal menù principale la voce Settings e poi Legacy Key Encryption. Selezionare la Organizzazione e premere il bottone [Inizialize Encryption]. Seguire le istruzioni a video e salvare la chiave in maniera sicura per eventuale uso futuro.
- Per iniziare a richiedere certificati SSL server è necessario creare almeno 1 dominio e validarlo (vedi la sezione "Gestione Dominii")
- Prima di richiedere un certificato EV (Extended Validation) leggere la sezione dedicata più sotto e considerare che la CA deve verificare il numero telefonico aziendale principale e pertanto è necessario che l'ufficio sia presidiato.
Aggiornamenti importanti
Durante il primo mese di utilizzo della nuova piattaforma abbiamo sperimentato alcuni problemi che hanno talvolta impedito l'emissione dei certificati. Ecco un elenco delle più importanti scoperte e soluzioni:
- certificati bloccati in stato Applied: verificare che il CAA record permetta a Sectigo l'emissione dei certificati (on-line check)
- errore in fase di approvazione richiesta "Please fill all empty required fields of organization/department": declinare la richiesta, modificare i privilegi di RAO e DRAO aggiungendo "SSL auto-approve" e sottomettere una nuova richiesta.
- errore in fase di richiesta certificato "Anchor Certificate address details are different!": ricreare una nuova CSR minimale usando il comando openssl
openssl req -nodes -newkey rsa:3072 -keyout myserver.key -out server.csr -subj "/C=IT/CN=mysubdomain.mydomain.com"
e sottomettere nuovamente - Sectigo SCM Error “Anchor Certificate details are different”: https://www.sectigo.com/knowledge-base/detail/Sectigo-Certificate-Manager-SCM-Error-Anchor-Certificate-details-are-different/kA03l000000noiG
- Se dopo aver chiesto nuovamente il certificato con la CSR minimale l'errore persiste contattate GARR CS <garr-ca@garr.it>.
- dopo aver installato un certificato su un server, controllare la configurazione della certificate chain: Paragrafo >> Installazione SSL certificate
- Non è consigliato abilitare utenti con il bottone [Add Idp User] perché per l'attivazione è necessario l'intervento manuale di un MRAO:
- non usare l'opzione se la Org non ha un Idp in IDEM,
- se si decide comunque di creare con [Add Idp User] poi scrivere a <garr-ca@garr.it> per l'attivazione,
- il modo migliore per accedere a SCM con Idp è creare l'utenza in Settings > Admins e nella sezione Authentication impostare il valore di SAML IDP a "Your Institution" e inserire il valore ePPN dell'utente nell'apposito spazio.
- Status dei sistemi Sectigo e prossimi aggiornamenti pianificati: https://sectigo.status.io/
Registration Authority Officer
Ogni organizzazione deve indicare nel documento di adesione 2 persone a cui sarà assegnato da GARR CS il ruolo di Registration Authority Officer (RAO) all'interno del portale Sectigo.
Attivazione dei primi 2 Registration Authority Officer (RAO)
Dopo la ricezione della documentazione di Adesione il servizio GARR CS procederà sul portale SCM alla creazione della Organizzazione e contestualmente alla creazione degli account per i due RAO indicati.
Dato che il portale SCM non prevede meccanismi dinamici di attivazione degli account è necessario poter comunicare out of band le credenziali per i primi 2 RAO, che inoltre devono essere riconosciuti dal GARR CS.
Per il riconoscimento e la trasmissione sicura delle credenziali, i RAO dovranno inviare un messaggio messaggio di posta elettronica firmato e cifrato come sotto indicato.
Una volta ricevute le credenziali temporanee riceverete una mail di conferma e sarà possibile accedere al portale SCM.
Trasmissione password temporanea e identificazione
La trasmissione della password temporanea deve avvenire con un testo criptato creato come indicato in Cifratura. L'identificazione avviene invece mediante firma digitale del messaggio di posta elettronica con cui viene trasmesso il testo criptato con le modalità indicate in Firma.
Cifratura
Accedere al sito https://keybase.io/encrypt e completare con i seguenti valori:
- Recipient: digitare, dipendentemente dall'operatore che vi ha inviato la mail di attivazione, "keybm" (Barbara Monticini) oppure "keydl" (Mario Di Lorenzo) e selezionare come destinatario
- Message to encrypt: scrivere a vostra scelta una password temporanea con cui sarà attivata la vostra utenza
- Bottone [Encrypt] per eseguire la cifratura del messaggio
Copiare tutto il testo -----BEGIN PGP MESSAGE----- ... -----END PGP MESSAGE----- comprese la prima e l'ultima riga e incollarlo in un nuovo messaggio di posta.
Firma
A partire dal messaggio creato al punto precedente, per l'invio firmato potete procedere in due modalità:
- apporre una firma S/MIME con il vostro client di posta e il vostro certificato digitale che può essere:
- un certificato personale rilasciato da TCS Digicert (solo per chi già ne possiede uno).
- un certificato personale per la firma qualificata.
- creare un documento di testo in cui sia dichiarata la vostra identità e nomina al ruo di RAO, firmarlo digitalmente anche con servizi di firma remota e allegarlo al messaggio. Questa modalità è utile anche per evitare l'invalidazione della firma dovuta a server di posta che modificano i messaggi in uscita.
Inviare il messaggio con destinatario <garr-ca@garr.it> e oggetto "Attivazione Account RAO per <Nome> <Cognome>".
Videoconferenza con il servizio GARR CS per l'identificazione e la consegna delle credenziali
Nel caso in cui non fosse possibile seguire la procedura di attivazione mediante firma e cifratura, in via eccezionale può essere concordata l'attivazione via videconferenza, tenendo conto che la priorità sarà data alle attivazioni che seguono la procedura ordinaria.
Contattare <garr-ca@garr.it> per fissare una videoconferenza in cui presentarsi e identificarsi con documento di identità (è richiesta una videocamera)
Accesso al Portale Sectigo Certificate Manager (SCM)
L'istanza del portale Sectigo Certificate Manager (SCM) per GARR è accessibile su:
https://cert-manager.com/customer/GARR
Al primo accesso il Portale proporrà il cambio password. Memorizzare la password in maniera opportuna.
Aggiunta e configurazione di Registration Authority Officer (RAO)
I RAO creati da GARR CS sono autorizzati ad aggiungere ulteriori RAO e DRAO.
Dal menù principale scegliere la voce Settings > Admins. La pagina presenta la tabella degli amministratori della vostra organizzazione (sia RAO che DRAO).
Inizialmente la tabella include soltanto i due RAO nominati nel documento di adesione.
Per inserire un nuovo amministratore premere il bottone verde (+) (per il momento SCONSIGLIAMO l'aggiunta di amministratori con il bottone [Add IdP User]).
La maschera di creazione di un nuovo amministratore (Add New Client Admin) permette di inserire i dati dell'utente.
Compilare almeno i campi obbligatori:
- Username
- Forename
- Surname
Premere [Next] per procedere nella creazione. Viene visualizzata una finestra in cui impostare Role & Privileges, Authentication ed editare i dati immessi finora (simbolo penna).
TAB "Role & Privileges"
In Role selezionare il ruolo per l'utente tra RAO e DRAO.
In Certificate Types indicare per quali tipo di certificati l'utente ricopre il ruolo selezionando l'interruttore e facendolo diventare verde. Per ogni tipo è possibile selezionare su quale eventuale Dipartimento sono applicati i poteri. E' possibile assegnare al RAO/DRAO tutti e 3 i ruoli oppure un sottoinsieme a seconda delle necessità. La configurazione può essere cambiata successivamente.
In Privileges è consigliabile assegnare sempre i primi 6 privilegi:
- Allow creation of peer admin users
- Allow editing of peer admin users
- Allow deleting of peer admin users
- Allow DCV
- Allow SSL details changing
- Allow SSL auto approve
Una nota speciale per i seguenti 2 privilegi:
- Allow SSL auto approve: se non abilitato, le richieste di certificati fatte da questo RAO dovranno essere sempre approvate dai RAO creati da GARR CS.
- WS API use only: usare solo se il RAO che si vuole creare non è una persona, ma un utente ad hoc da utilizzare in programmi e script che consumino le API di Sectigo accessibili via Web Service. Se il controllo viene impostato a true il RAO non potrà accedere al Portale in modalità GUI.
TAB "Authentication"
Password
La password impostata per il nuovo amministratore dovrà essere comunicata out-of-band al collega il quale potrà in seguito accedere al portale SCM.
Client Certificate
E' possibile selezionare uno dei certificati emessi per l'utente (solitamente da attivare in un secondo momento dopo che l'utente ha richiesto un certificato nel sistema SCM).
SAML IDP
Serve per collegare l'account all'autenticazione via SAML con la Federazione IDEM e va configurato solo se il vostro Ente partecipa alla Federazione e solo dopo aver configurato l'identity provider con le istruzioni riportate nell'apposita sezione dedicata.
Impostare il valore di SAML IDP a "Your Institution" e inserire il valore ePPN dell'utente nell'apposito spazio.
Modifica di un Admin
Per modificare un amministratore già creato in precedenza selezionare dalla tabella degli amministratori la radio button relativa e premere il bottone [Edit].
La maschera di modifica di un amministratore (Edit Client Admin) è sostanzialmente identica alla maschera di creazione nuovo amministratore: sono presenti i TAB "Role & Privileges" e "Authentication". Inoltre in alto a destra è presente il simbolo di una Matita che permette di accedere alla sezione in cui modificare i dati del profilo (email, telefono, indirizzo, città, cap, nazione).
Rispetto alla maschera di creazione qui è presente la sezione con il link Reset password.
Reset della password
Il reset della password di un account RAO può essere fatto da un qualsiasi altro RAO della stessa Organization. Dal menù Settings > Admins selezionare il nome dell'amministratore da modificare, premere il bottone [Edit] e premere il bottone del TAB Authentication denominato [Reset password]. La nuova password dovrà essere comunicata out-of-band al collega.
Gestione Dominii
Tempo di Lettura: 5 minuti
Per emettere certificati (sia a livello di Organizzazione che di Dipartimento) è prima di tutto necessario creare un dominio, delegarne la gestione alla propria organizzazione (e/o dipartimento) e validarlo.
Prima di inserire una nuovo dominio accertarsi che il dominio sia intestato all'Ente o che rispetti le regole specificate nella pagina TCSVerificaDomini.
Creazione dominio (sia ruolo RAO che DRAO)
Dal menù principale selezionare Domains, premere il bottone verde (+) in alto a destra.
Nella finestra che si apre inserire il dominio alla voce Domain. Più sotto selezionare l'organizzazione o il dipartimento a cui delegare il dominio e il tipo di certificato da delegare. Premere il bottone [SAVE] per confermare.
Di default tutti i tipi di certificati disponibili sono abilitati per il dominio, se si vuole disabilitarne alcuni eliminare la spunta dalla casella corrispondente.
IMPORTANTE Ripetere i passaggi precedenti aggiungendo nuovamente il dominio prefisso da
*.
, ad esempio se avete creato il dominioente.org
, adesso dovrete creare*.ente.org
.
Una volta creati i dominii, si deve attendere che le deleghe di gestione all'Organizzazione siano approvata dagli MRAO e che le deleghe di gestione al Dipartimento siano approvate dal RAO a cui il dipartimento afferisce. Il richiedente riceverà una notifica non appena la deleghe saranno state approvate.
Esempi pratici:
Problema: richiedere certificati per il dominio garr.it Soluzione: creare i domini garr.it e *.garr.it -> attendere la delega del MRAO -> validare il dominio garr.it
Problema: assegnare al dipartimento "mioDept" il sotto dominio miodept.garr.it per richiedere certificati per il sotto dominio miodept.garr.it Soluzione: creare i domini miodept.garr.it e *.miodept.garr.it -> attendere la delega del RAO -> la validazione è automatica
Validazione dominio
Per conoscere i metodi di validazione DCV è disponile il seguente articolo di Sectigo: https://sectigo.com/knowledge-base/detail/Domain-Control-Validation-DCV-Methods/kA01N000000brbt
Dal menù principale selezionare Domains, selezionare il dominio da validare dalla lista dei domini disponibili e nel riquadro Domain Control Validation (DCV) premere il bottone [Validate] . Attenzione: possono essere validati solo i domini SENZA asterisco.
NOTA BENE: Di default solo i primi 2 RAO di ogni nuova ORG creata in SCM hanno i permessi utili ad iniziare il DCV. Per tutti i successivi RAO, creati internamente da altri RAO, i privilegi vanno aggiunti manualmente da parte di un MRAO. Scrivere a <garr-ca@garr.it> (in cc almeno un altro collega RAO) indicando il nominativo del RAO a cui far aumentare i privilegi.
Nella finestra che si apre selezionare il metodo di validazione del dominio. Le scelte possibili sono Email, HTTP, HTTPS, CNAME, a seconda della scelta sono presentati requisiti diversi:
- Email: selezionare l'indirizzo a cui Sectigo invierà il messaggio di controllo.
- CNAME: seguire le istruzioni che consistono nel creare un record DNS di tipo CNAME con il valore indicato sul dominio da validare
!!! ATTENZIONE !!!: Prima di considerare l'impiego dei metodi HTTP / HTTPS leggere attentamente e capire le possibili implicazioni per i certificati widcard e per la validazione dei sottodomini nel documento: https://sectigo.com/resource-library/modifications-to-available-file-based-methods-of-domain-control-validation
- HTTP: seguire le istruzioni che consistono nel creare un file txt contenente un codice generato da Sectigo e posizionarlo in una location well-known sul server web attivato sul dominio da validare.
- HTTPS: come per HTTP, ma la location sarà in HTTPS.
Una volta scelto il metodo desiderato premere [Next] ed annotare le eventuali istruzioni presenti nella pagina successiva prima di premere il bottone [Submit] per avviare la validazione. Nella pagina principale che contiene i dettagli del dominio sarà possibile cancellare la richiesta di validazione e ripartire da capo premendo il bottone [simbolo del Cestino] alle voci DCV Status e DCV Order Status.
IMPORTANTE I dominii con prefisso
*.
sono validati contestualmente al dominio a cui sono associati ma graficamente lo saranno con uno o più giorni di attesa in più rispetto al dominio principale a cui sono collegati.
Rimozione / Cambio della Validazione dominio
Per cancellare una validazione non terminata o per cambiare il tipo di validazione (es. da EMAIL a CNAME, da HTTP a EMAIL) usare il simbolo del cestino accanto alla voce DCV Status che appare selezionando da Domains la checkbox del dominio su cui vogliamo operare.
In generale per i sottodomini non dovrebbe essere richiesto un processo di validazione separato perché di default ereditano la validazione del dominio padre.
Validazione annuale dei dominii
La validazione dei dominii ha durata annuale ed è possibile ripeterla solo nei 30 giorni precedenti la scadenza. GARR-CS ha attivato una notifica automatica che 20 giorni prima della scadenza avvertirà i RAO relativamente al dominio in scadenza.
La procedura di ri-validazione è identica alla DCV descritta in Validazione dominio.
Cancellazione di domini esistenti
Per cancellare un dominio da SCM scrivere a garr-ca@garr.it (mettendo in copia anche un altro collega RAO) ed indicare il nome del dominio da rimuovere.
Emissione Certificati
Quanto segue riguarda l'emissione di certificati tramite portale SCM da parte degli Admins, ovvero RAO e DRAO.
Per informazioni sull'emissione automatizzata tramite ACME/certbot fare riferimento alla sezione ACME account.
Prima di procedere con la richiesta di certificati GÉANT EV SSL e GÉANT EV Multi-Domain consigliamo di consultare la sezione dedicata più sotto.
Per poter richiedere tutti i certificati di tipo GÉANT IGTF (grid, sia server che personali) è necessario compilare e validare il "Secondary Organization Name" seguendo le istruzioni della sezione dedicata più sotto.
L'emissione di un certificato SSL deve sempre essere approvata da un RAO (o DRAO, a seconda di come è stata organizzata la Org).
Se un RAO/DRAO ha nel proprio account la spunta sul privilegio "Allow SSL auto approve" (in Admin > cercare il RAO, selezionarlo e premere [Edit]) allora tutte le richieste di certificato da lui sottomesse saranno automaticamente approvate senza ulteriori passaggi.
In caso contrario le richieste dovranno essere approvate manualmente:
- alla ricezione della mail "SSL certificate for (<CN del certificato>) AWAITING APPROVAL" copiare il valore di Order Number
- in SCM, dal menù principale Certificates > SSL Certificate > cercare filtrando per Order Number > spuntare la riga ottenuta (che è in stato requested) e proseguire premendo il bottone [APPROVE] .
Richiesta SSL Certificate (What is a CSR?)
Dal menù principale selezionare Certificates, poi SSL Certificates e premere il bottone verde [+] in alto a destra.
Nella finestra che si apre (Request SSL Certificate) si deve scegliere la modalità di creazione tra:
- Using a CSR: creare la private key e la CSR (Certificate Signing Request) in locale e copiare la CSR sul form della schermata successiva.
- Generation of CSR: la CSR e la private key sono create sul portale. (Modalità non attivabile)
- Generation of CSR with auto installation: riguarda le organizzazioni che si avvalgono dei Network Agents --- vedi documentazione Sectigo.
- Generation of CSR in Azure Key Vault: riguarda le organizzazioni che hanno configurato la Azure Key Vault. (Modalità non attivabile)
Using of CSR
Una volta selezionata la modalità Using of CSR, premere il bottone [Next], nella schermata succesiva inserire le informazioni richieste (obbligatori: Organization, Certificate Profile e Certificate Term (default 1 year) e premere [Next], nella schermata successiva caricare o incollare la CSR nel form e premere il bottone [Next]. Per creare la CSR e la relativa chiave potete utilizzare il seguente comando openssl:
openssl req -nodes -newkey rsa:3072 -keyout myserver.key -out server.csr -subj "/C=IT/CN=mysubdomain.mydomain.com"
Certficate Profile: selezionare GÉANT OV SSL per un certificato SSL per un solo nome di dominio o GÉANT OV Multi-Domain per aggiungere SAN (Subject Alternative Names).
Importante: nei certificati GÉANT OV SSL viene aggiunto in automatico un Subject Alternative Names che riporta il valore del CN ed eventualmente la versione con prefisso www. . Per questo motivo consigliamo di richiedere certificati GÉANT OV Multi-Domain anche quando la richiesta presenta un solo fqdn.
Completare la richiesta indicando gli eventuali SAN (Subject Alternative Names) nel caso si stia richiedendo un certificato GÉANT OV Multi-Domain. Di default sono presi direttamente dalla CSR ma possono anche essere aggiunti manualmente in questa fase (Use commas or spaces to separate multiple values for bulk input.)
Nella schermata successiva ci verrà richiesto se abilitare o meno il rinnovo automatico, Enable auto renewal of this certificate, e quanti giorni prima iniziare il processo.
E' sempre possibile verificare tramite SCM se per un certificato è stato abilitato l'auto-rinnovo: dal menù principale Certificates > SSL Certificate > cercare filtrando per il nome del server > spuntare la riga del certificato in corso di validità (di solito ISSUED e in verde) e premere [View]. Se nei dettagli appare Auto-renew SUCCESSFUL o Auto-renew SCHEDULED allora l'auto-rinnovo è stato impostato. Nella sezione Details del certificato è possibile vedere chi è l'owner del certificato selezionando la voce Owner.
Certificati Extended Validation (GÉANT EV SSL e GÉANT EV Multi-Domain)
Nonostante questo tipo di certificato possa essere richiesto attraverso il modulo standard di richiesta certificati vi preghiamo di considerare la possibilità di validare a priori l'emissione dei certificati EV per la vostra Organizzazione grazie al meccanismo chiamato EV Anchor.
Come nei precedenti contratti TCS ricordiamo che il tipo EV richiede, per l'emissione di un certificato, un livello di validazione molto alto e questo può creare lunghi tempi di attesa. EV Anchor, una volta ottenuta, permette di velocizzare la validazione dei successivi certificati EV creando appunto un'ancora riutilizzabile dall'Organizzazione. EV Anchor ha validità di un anno.
Cosa succede se non sfrutto il meccanismo EV Anchor? Per ogni nuova richiesta di certificato EV si dovrà contattare il team di validazione Sectigo attraverso il sistema di ticketing https://sectigo.com/support-ticket.
La mia organizzazione vuole attivare EV Anchor, cosa dobbiamo fare? Stabilire l'elenco dei domini per i quali il vostro Ente è interessato a ottenere certificati EV e assicurarsi di aver creato i domini all'interno del portale SCM. Per capire in cosa consiste la validazione EV consultare la documentazione: Sectigo Extended Validation Explained. In seguito contattare <garr-ca@garr.it> per gli ulteriori passaggi.
Certificati GÉANT IGTF Multi Domain (grid)
Per poter richiedere certificati GÉANT IGTF Multi Domain (grid) è necessario validare il "Secondary Organization Name". Per procedere: scrivere un ticket a <garr-ca@garr.it> per chiedere agli amministratori MRAO di compilare il campo "Secondary Organization Name". Nello scegliere il valore del campo prestare attenzione che contenga solo caratteri ASCII. Se, già con Digicert, venivano emessi certificati "grid utente" assicurarsi di impostare il campo "Secondary Organization Name" identico al campo O usato con Digicert (in caso di dubbio consultare il portale Digicert per controllo). Motivazione: Dato che il subject dei certificati grid utente è usato come "username" è fondamentale che questo rimanga inalterato per non causare problemi agli utenti nell'accesso alla grid. Gli amministratori MRAO faranno contestualmente partire la validazione del "Secondary Organization Name" che permetterà dipoter iniziare a richiedere certificati grid.
A partire dal giorno 3 Ottobre 2020 non più possibile personalizzare i campi presenti nel distinguished name (DN) dei certificati emessi. Su richiesta della comunità GÉANT TCS i certificati IGTF sono emessi con uno speciale "Certificate Profile" che non include nel DN i campi streetAddres, postalCode e stateProvince.
Richiesta certificati SSL tramite autenticazione SAML (per utenti non admin)
È possibile richiedere certificati SSL con autenticazione basata su autenticazione federata SAML via IDEM. In questo modo sarà possibile far richiedere i certificati anche ad utenti che non siano RAO o DRAO. Nel portale SCM questa funzionalità è definita Self Enrollment.
Per abilitare il Self Enrollment selezionate dal Menù principale Enrollments, poi premere il bottone [(+)].
Nella finestra che si aprirà selezionare "SSL SAML self-enrollment form", dare un nome all'Endpoint e premere [Next]
Nella finestra successiva generare la "URI Extension" premendo il bottone [Generate].
Come funziona: L'accesso averrà tramite la URL generata (mostrata in Endpoint URL) e con autenticazione SAML. In questo modo l'accesso sarà limitato ai soli utenti della propria organizzazione e tutti gli accessi saranno autenticati su base personale.
Raccomandiamo di non spuntare la casella Automatically Approve Self Enrollment Requests per mantenere il controllo delle richieste di certificati SSL richiesti tramite Self Enrollment. È inoltre possibile limitare i tipi di certificati che si possono richiedere tramite la scelta dei Profili associati all'Endpoint (tabella Profiles).
Una volta terminata la configurazione del Self Enrollment premendo il bottone [Save], distribuire ai colleghi le URL del nuovo Endpoint per la richiesta dei certificati.
SSL Certificate Enrollment: accesso ed emissione
Gli utenti che accederanno alle URL del SSL Certificate Enrollment dovranno autenticarsi tramite il proprio Identity Provider.
Una volta acceduti dovranno selezionare il Certificate Type, il Certificate Term ed il Server Software per cui stanno richiedendo il certificato ed incollare la Certificate Signing Request nel campo CSR, i campi rimanenti sono opzionali. Una volta premuto il bottone [ENROLL] il RAO riceverà una notifica di richiesta e potrà approvare la richiesta del certificato dal menù Certificates del portale SCM.
Una volta approvata la richiesta ed emesso il certificato, l'utente riceverà infine un messaggio di posta elettronica contenente i link per scaricare il certificato richiesto.
Approvazione di Richieste per SSL Certificate
L'emissione di un certificato SSL deve sempre essere approvata da un RAO (o DRAO, a seconda di come è stata organizzata la Org).
Se un RAO/DRAO ha nel proprio account la spunta sul privilegio "Allow SSL auto approve" (in Admin > cercare il RAO, selezionarlo e premere [Edit]) allora tutte le richieste di certificato da lui sottomesse saranno automaticamente approvate senza ulteriori passaggi.
In caso contrario le richieste dovranno essere approvate manualmente:
- alla ricezione della mail "SSL certificate for (<CN del certificato>) AWAITING APPROVAL" copiare il valore di Order Number
- in SCM, dal menù principale Certificates > SSL Certificate > cercare filtrando per Order Number > spuntare la riga ottenuta (che è in stato requested) e proseguire premendo il bottone [APPROVE] .
Installazione SSL Certificate
Dopo aver installato il certificato verificare di aver configurato in maniera ottimale la certificate chain con uno dei seguenti 2 metodi:
- testando la configurazione in https://www.ssllabs.com/ssltest/
- usando il comando OpenSSL:
openssl s_client -connect myserver.mydomain.org:443
Interpretare i risultati:
- tra i risultati del test Qualys SSL Labs cercare la voce "Chain issues" ed assicurarsi che sia visualizzato il valore "None"
- l'output del comando Openssl deve contenere solo la seguente certificate chain:
Certificate chain
0 s:C = IT, O = Consortium GARR, CN = cert.test.garr.it
i:C = NL, O = GEANT Vereniging, CN = GEANT OV RSA CA 4
1 s:C = NL, O = GEANT Vereniging, CN = GEANT OV RSA CA 4
i:C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority
Soluzione:
Per correggere eventuali problemi configurare come certificate chain solo i certificati delle CA intermedie di GÉANT (ad esempio CN = GEANT OV RSA CA 4 e simili).
Consultazione dei certificati SSL
Oltre al portale SCM di Sectigo in cui ogni RAO e DRAO può consultare rispettivamente lo status dei certificati della propria Organization e del proprio Department, esiste anche un portale open source disponibile a tutta la comunità internet. Il portale è raggiungibile all'indirizzo https://crt.sh/ e la ricerca può avvenire sulla base dei più svariati parametri (Domain Name, Organization Name, Certificate Fingerprint e tutti quelli inclusi nella sezione Advanced).
Richiesta Client Certificate via SCM con invito (solo per GÉANT IGTF-Classic-Robot Email "GÉANT Organisation Automated Authentication")
La richiesta di Client Certificate da parte degli Admin via portale SCM è piuttosto scomoda e soprattutto non scalabile per un numero elevato di certificati. La soluzione consigliata è la richiesta via autenticazione federata con SAML (vedi paragrafo successivo).
L'unico tipo di certificato ordinabile in SCM è "GÉANT IGTF-Classic-Robot Email" "GÉANT Organisation Automated Authentication" e trattandosi di un certificato IGTF è necessario configurare la propria Org per la richiesta di certificati IGTF (grid):
- Scrivere una mail a <garr-ca@garr.it> per chiedere agli amministratori MRAO di modificare e far partire la validazione del "Secondary Organization Name".
- Comunicare nella mail il valore del campo "Secondary Organization Name" prestando attenzione che contenga solo caratteri ASCII e che sia identico al campo O eventualmente usato in precedenza per i certificati grid con Digicert (in caso di dubbio consultare il portale Digicert per controllo). Dato che il subject dei certificati grid è usato come "username" è fondamentale che questo rimanga inalterato per non causare problemi di accesso alla grid per gli utenti.
Per richiedere un certificato "GÉANT IGTF-Classic-Robot Email" "GÉANT Organisation Automated Authentication" via SCM per un membro della propria organizzazione selezionare Persons e premere il bottone verde (+). Se la persona fosse già stata creata in precedenza selezionare la riga corrispondente e saltare direttamente più sotto alle istruzioni relative al TAB Enrolment Invitation.
Nella finestra che si apre devono essere indicati o confermati:
- Organization ed eventualmente Department,
- alla voce Domain va selezione il dominio su cui emettere il certificato,
- in First Name il nome proprio ed in Last Name il cognome.
- in Email Address va inserita la parte locale (a sinistra della @domain) dell'indirizzo di posta che sarà associato al certificato.
Proseguire con [Next]
- in Common Name inserire il nome dell'utente che verrà visualizzato nel certificato
- (opzionale) in Secret impostare un valore specifico per questo utente.
Una volta terminato l'inserimento premere il bottone [Save].
Selezionare il nuovo utente creato e premere il bottone [Edit].
Proseguire nel TAB Enrolment Invitation
- Premere (+) su Invitation per creare l'invito
- Compilare i parametri dell'invito considerando che l'unico Certificate Profile funzionante è
GÉANT IGTF-Classic-Robot Email GÉANT Organisation Automated Authentication)
Una volta terminato l'inserimento premere il bottone [Save].
Se la configurazione è andata a buon fine allora la persona riceverà una mail con oggetto "Invitation Email - You have requested email certificate validation" contenente le istruzioni per richiedere il certificato.
Ricordiamo che l'unico profilo funzionante è GÉANT Organisation Automated Authentication e la scelta di qualsiasi altro Profilo produrrà un errore.
Richiesta Client Certificate con portale self-service via SAML
Il portale per la richiesta self-service dei certificati personali (client certificate), personali IGTF (email e robot) è https://cert-manager.com/customer/garr/idp/clientgeant
L'accesso è possibile solo tramite autenticazione federata con IDEM e previa configurazione dell'Identity Provider istituzionale (sezione Configurazione SAML).
Dal 1 settembre 2023 sono entrate in vigore nuove regole relative al rilascio dei certificati personali emessi da CA pubbliche secondo quanto specificato dal documento https://cabforum.org/wp-content/uploads/CA-Browser-Forum-SMIMEBR-1.0.0.pdf
Per emettere certificati S/MIME ("GÉANT Personal email signing and encryption") è necessario l'Organizzazione in SCM sia stata rivalidata dopo il 1 settembre 2023. Tra i requisiti introdotti dalle nuove regole S/MIME: la persona che richiede il certificato deve avere associato in SCM una Person con Validation Type = HIGH e nei campi Nome e Cognome deve essere presente il nome e cognome di una persona concreta .
Per emettere certificati IGTF/grid ("GÉANT Personal Authentication" e "GÉANT Personal Automated Authentication") è necessario l'Organizzazione abbia impostato in SCM un Secondary Organization Name e che questo sia stato validato.
Le nuove root e intermediate CA di Géant sono disponibili in: https://wiki.geant.org/display/TCSNT/TCS+Trust+Anchors+and+Intermediates
Configurazioni
Configurare la richiesta di certificati personali
- L'Identity Provider deve rilasciare un determinato insieme di attributi al Service Provider Sectigo. Dettagli nella sezione Configurazione SAML
- In SCM, selezionare Organizations, selezionare la propria organizzazione e premere il bottone [Edit]. Nella finestra di modifica editare il campo "Academic code (SCHAC Home Organization)" inserendo il valore stabilito per l'attributo schacHomeOrganization rilasciato dall'Identity Provider. Generalmente coincide con il valore del dominio principale, o scope, ma conviene coordinarsi con l'idp manager.
Configurare anche la richiesta di certificati IGTF (grid)
- Scrivere un ticket a <garr-ca@garr.it> per chiedere agli amministratori MRAO di modificare e far partire la validazione del "Secondary Organization Name".
- Comunicare nel ticket il valore del campo "Secondary Organization Name" prestando attenzione che contenga solo caratteri ASCII e che sia identico al campo O eventualmente usato in precedenza per i certificati grid con Digicert (in caso di dubbio consultare il portale Digicert per controllo). Dato che il subject dei certificati grid è usato come "username" è fondamentale che questo rimanga inalterato per non causare problemi di accesso alla grid per gli utenti.
Richiesta di client certificate tramite portale self-service via IDEM/SAML
- Andare su https://cert-manager.com/customer/garr/idp/clientgeant ed autenticarsi con il proprio IDP.
- Selezionare il tipo di certificato:
- "GÉANT Personal email signing and encryption" certificati personali emessi da un CA pubblica per la firma e la cifratura di email ma non per la firma di documenti o la client authentication. [Il Profilo, anche se disponibile nel menù a tendina, permette l'emissione dei certificati solo se la Org è stata rivalidata dopo il 1 settembre 2023]
- Novità da settembre 2023:
- la persona (Persons) che richiede il certificato via SAML acquisisce (in automatico) la proprietà "Validation Type" = HIGH ed i campi First e Last Name vengono sovrascritti se diversi dai valori degli attributi SAML givenName e sn trasmessi dall'Identity Provider. Usare https://cert-manager.com/customer/garr/ssocheck/ per conoscere quali valori degli attributi SAML givenName e sn sono trasmessi dall'Identity Provider.
- La generazione del certificato impiega più di un minuto per completare.
- Novità da settembre 2023:
- "GÉANT Personal Authentication" certificati personali emessi da una CA privata da usare in ambito grid/IGTF e per la client authentication. Non adatti per la firma e la cifratura di email e per la firma di documenti. [Il Profilo, anche se disponibile nel menù a tendina, permette l'emissione dei certificati solo se la Org ha impostato e validato il Secondary Organization Name]
- "GÉANT Personal Automated Authentication" certificati personali robot emessi da una CA privata da usare in agenti software che si autenticano per conto dell'utente (ambito grid/IGTF). Non adatti per la firma e la cifratura di email e per la firma di documenti. [Il Profilo, anche se disponibile nel menù a tendina, permette l'emissione dei certificati solo se la Org ha impostato e validato il Secondary Organization Name]
- "GÉANT Personal email signing and encryption" certificati personali emessi da un CA pubblica per la firma e la cifratura di email ma non per la firma di documenti o la client authentication. [Il Profilo, anche se disponibile nel menù a tendina, permette l'emissione dei certificati solo se la Org è stata rivalidata dopo il 1 settembre 2023]
- Selezionare se si desidera che la chiave privata sia generata server-side o localmente:
- Scegliere "Generate RSA" se si vuole un certificato con chiave privata generata server-side.
- Scegliere "Generate ECC" se si vuole un certificato con chiave privata generata server-side e se si è interessati a testare i certificati ECC.
- RACCOMANDATO Scegliere "Upload CSR" se non si vuole che la chiave privata sia generata server-side ma si vuole fornire una CSR generata in autonomia.
- Di seguito trovate le istruzioni per la creazione della chiave e della CSR con OpenSSL:
- Creazione CSR con chiave RSA a 3072 bit:
openssl req -newkey rsa:3072 -keyout nome_cognome-key.pem -out nome_cognome-csr.pem -subj "/CN=Nome Cognome"
- Creazione CSR con chiave ECC a 256bit:
openssl req -newkey ec:<(openssl ecparam -name prime256v1) -keyout nome_cognome-key.pem -out nome_cognome-csr.pem -subj "/CN=Nome Cognome"
- Creazione CSR con chiave RSA a 3072 bit:
- Di seguito trovate le istruzioni per la creazione della chiave e della CSR con OpenSSL:
- Se si è scelto di generare il certificato server-side è necessario compilare il campo password con cui sarà cifrato il file PKCS#12 generato per voi.
- Choose key protection algorithm: "Compatible TripleDES-SHA1"
- Premere "Submit" e accettare il contratto di licenza.
- In pochi istanti avverrà il download del certificato. Il formato dipende dalle scelte fatte durante la richiesta:
- Con "Generate RSA/ECC", si riceverà un file PKCS#12 con nome certs.p12 contenente chiave privata e certificato (file cifrato con la password scelta). Tale certificato potrà essere importato nel browser e nel client di posta con la funzione "Import Certificate" o similare.
- Con "Upload CSR", si riceverà un file PEM-formatted chiamato certs.pem e contenente il certificato personale, il certificato intermedio della CA ed il root certificate di Sectigo . Per poter utilizzare il certificato per la firmare e crittografare i messaggi di posta elettronica è necessario creare un file in formato PKCS#12 contenente sia il certificato, sia la chiave. E' possibile farlo utilizzando OpenSSL con il seguente comando:
openssl pkcs12 -export -in certs.pem -inkey nome_cognome-key.pem -out nome_cognome.p12
Gestione dei Certificati Personali
Le risorse messe a disposizione da Sectigo sono molto carenti per quanto riguarda la gestione dei certificati personali per l'utente finale.
Il RAO rappresenta il punto di riferimento unico per poter consultare lo status dei certificati personali emessi a nome di un utente.
Ogni utente può avere attivi al massimo due certificati per tipologia. A partire dal terzo certificato emesso nella stessa tipologia, se il computo totale dei certificati attivi equivalesse a 3, verrà revocato automaticamente da Sectigo il certificato più vecchio ancora valido in quella tipologia.
Revoca dei certificati personali
La revoca può essere richiesta ad uno dei RAO della proprio Organizzazione o tramite ticket al supporto di Sectigo https://sectigo.com/support-ticket.
I certificati emessi prima del 18 Marzo 2022 possono essere revocati solo tramite ticket al supporto di Sectigo https://sectigo.com/support-ticket.
Verificare se un certificato personale è stato revocato
Esistono due modi per scoprire questa informazione:
- contattare uno dei RAO della propria Organizzazione;
- consultare la cosiddetta CRL ovvero l'elenco dei certificati revocati dalla CA. Il procedimento da seguire è indicato qui sotto.
E' necessario disporre dei seguenti elementi:
- software Openssl
- certificato personale salvato su file (da cui ricavare il serial number, istruzioni fornite qui sotto)
- file CRL (la cui location è ricavabile dal file precedente, istruzioni fornite qui sotto)
Salvare il certificato personale su file (ad esempio "cert.crt") estraendolo dal proprio Browser o dal proprio Client di Posta (seguire le istruzioni del software in uso).
Per ricavare la location della CRL eseguire il comando openssl:
openssl x509 -in cert.crt -noout -text | grep crl
Appena ottenuta la url della crl scaricarla con il comando wget:
wget <url-ottenuta-dal-comando-precedente>
Estrarre il serial number del proprio certificato personale con il seguente comando:
openssl x509 -in cert.crt -noout -serial
Adesso è possibile scoprire se il serial number del nostro certificato è stato revocato:
openssl crl -inform DER -text -in [name of downloaded CRL] | grep [serial number of client's certificate you would like to check]
Esempio a partire da un file .p12:
openssl pkcs12 -in ../Desktop/certificato.p12 -nokeys -out certificato.crt
openssl x509 -in certificato.crt -noout -text | grep crl URI:http://pippo-pluto-paperino.crl
wget http://pippo-pluto-paperino.crl
openssl x509 -in certificato.crt -noout -serial serial=BD8DFB1FE2EEF98C7329CEE026C38009
openssl crl -inform DER -text -in pippo-pluto-paperino.crl | grep BD8DFB1FE2EEF98C7329CEE026C38009
Se la stringa non viene trovata allora il certificato non è stato revocato.
Se invece viene visualizzato il serial number allora il certificato è stato revocato. Come nel caso seguente:
openssl crl -inform DER -text -in pippo-pluto-paperino.crl | grep BD8DFB1FE2EEF98C7329CEE026C38009 Serial Number: BD8DFB1FE2EEF98C7329CEE026C38009
Richiesta Document Signing Certificate
E' possibile ordinare certificati Document Signing su un token USB preconfigurato da Sectigo.
I costi dei token USB non sono coperti dal servizio TCS e sono a carico del richiedente.
Per fare un ordine collegarsi a: https://www.sectigo.com/ssl-certificates-tls/document-signing-certificates e usare il codice sconto: QQY1XB49V9
Richiesta Code Signing Certificate
Descrizione del servizio a partire da maggio 2023
Dall'8 maggio 2023 sarà possibile ordinare certificati Code Signing solo impiegando device FIPS conformi a specifici standard HSM oppure direttamente su token forniti da Sectigo.
Uso di dispositivi propri - Se si intende usare dispositivi propri, considerare nell'acquisto che solo i seguenti sono supportati:
- Thales/Safenet Luna netHSM (solo per chiavi RSA) - deve essere un Luna: Luna HSM V7.x e Luna Cloud HSM (https://cpl.thalesgroup.com/it/encryption/hardware-security-modules/network-hsms)
- Yubico FIPS Yubikeys (solo per chiavi ECC) - https://www.yubico.com/products/yubikey-fips/
Acquisto di dispositivi da Sectigo - I costi dei token USB non sono coperti dal servizio TCS e sono a carico del richiedente.
Per fare un ordine collegarsi a: https://www.sectigo.com/ssl-certificates-tls/code-signing e usare il codice sconto: 2GE8AFN0T1
Dispositivi non supportati - Se si dispone di un dispositivo specifico che non è attualmente supportato, si prega di informare <garr-ca@garr.it>.
Ulteriori informazioni e guide sono disponibili qui: https://sectigo.com/knowledge-base/detail/Changes-to-Sectigo-Code-Signing-Offerings/kA03l000000BoIs.
Istruzioni a partire da Maggio 2023
E' stato creato sul portale SCM di GARR un nuovo Profilo specifico per richiedere i certificati Code Signing su dispositivi FIPS già posseduti "HSM Code Signing".
Il Profilo "SECTIGO Public CA CS Certificate Profile" per l'acquisto dei certificati emessi su dispositivo FIPS e spediti da Sectigo è stato disabilitato nel Portale SCM (contattare garr-ca@garr.it per l'abilitazione).
(Solo la prima volta) Creazione da parte del RAO di un Account per certificati su dispositivo FIPS già posseduto
Uno dei RAO deve creare un Account per la propria ORG seguendo il percorso dal Menù Principale Enrollment >> Enrollment Forms. Da qui spuntare la voce "Code Signing certificate on supported HSM". In alto apparirà il bottone [Accounts]. Premendo sul bottone si aprirà la finestra "Code Signing Web Form Accounts" che contiene la lista degli Account già creati dalla community GARR TCS. Creare il nuovo Account tramite il bottone verde (+) in alto a destra e compilando i campi della form come segue:
- Name = HSM Code Signing <nome ORG>
- Organization = scegliere la propria tramite menù a tendina
- Department = (opzionale)
- Profiles = "HSM Code Signing"
- CSR Generation Method = "Provided by user"
Salvare le impostazioni e ritornare al Menù Principale.
(Per ogni nuovo certificato Code Signing su dispositivo FIPS già posseduto) Creazione di un invito da parte del RAO
Uno dei RAO deve creare un Invito per il richiedente seguendo il percorso dal Menù Principale Certificates >> Code Signing Certificates.
Cliccare sul bottone in alto a destra [Invitations].
Si aprirà una finestra pop-up chiamata "Invitations" in cui per proseguire è necessario premere il bottone verde [+] in alto a destra.
Si aprirà una maschera che permette l'inserimento dei dati della persona che richiede il certificato Code Signing.
- Compilare il campo Email con l'indirizzo email del richiedente.
- Compilare Enrollment Endpoint selezionando dal menù la voce "Code Signing certificate on supported HSM".
- Compilare Account scegliendo dal menù l'account creato per la propria ORG (esempio "HSM Code Signing <nome-org>")
Completare il processo cliccando su "Send". Il richiedente riceverà una mail con le istruzioni e il link per procedere alla creazione del certificato.
(Per ogni nuovo certificato Code Signing su dispositivo FIPS già posseduto) Creazione della CSR e della Key Attestation da parte dell'utente
Inizializzare il dispositivo HSM secondo le istruzioni del Produttore personalizzando PIN, PUK e Key Management (!!! non lasciare i valori di default !!!)
Seguire le istruzioni di Sectigo presenti in questa Guida "Sectigo_CodeSigningCertificate_AdminGuide_Enterprise" sezione "3. CSR and Key Attestation Creation", scaricabile in fondo a questo link https://sectigo.com/knowledge-base/detail/Changes-to-Sectigo-Code-Signing-Offerings/kA03l000000BoIs.
Note sull'uso di Yubico Yubikeys:
- Usare solo YubiKey 5 FIPS Series
- Usare solo algoritmi ECC
- La shell deve essere avviata con permessi di Administrator
- Il comando
type attestation.crt intermediateCA.crt > attestation.pem
potrebbe introdurre caratteri non idonei che impediscono successivamente di sottomettere la richiesta. Ottenere la concatenazione dei file usando Notepad (o qualsiasi altro software) con permessi amministrativi. - Il comando
findstr /v CERTIFICATE attestation.b64 > attestation.b64
può essere sostituito dall'uso di Notepad (o qualsiasi altro software) con permessi amministrativi rimuovendo manualmente le linee di header/footer dal fileattestation.b64
Note sull'uso di Luna Network Attached HSM 7.x:
- processo non ancora testato
(Per ogni nuovo certificato Code Signing su dispositivo FIPS già posseduto) Sottomissione della richiesta e scarico del certificato da parte dell'utente
Il richiedente che riceve la mail di invito dovrà:
- Cliccare su "Verify Email Address" o copiare e incollare nel browser il link contenuto nella mail. Il link connette l'utente alla URL di sottomissione richiesta. La form di richiesta "Code Signing Enrollment" potrebbe risultare già parzialmente compilata.
- Completare la compilazione della form facendo riferimento alla tabella sottostante.
- Accettare la "user agreement" e premere [Submit]
Se la CSR e la key attestation sono valide, il richiedente riceverà una mail con il link per scaricare il certificato da Sectigo. Scaricare il certificato sul computer ed importarlo sul dispositivo HSM seguendo le istruzioni del Produttore.
Campo | Descrizione |
---|---|
Certificate email | email del richiedente (!!! il dominio deve coincidere con uno di quelli delegati alla ORG di appartenenza !!!) |
First name | nome del richiedente |
Last name | cognome del richiedente |
CSR | CSR in formato PEM. Le linee di header/footer sono necessarie e non vanno rimosse |
Key Attestation | Contenuto del file attestation.b64 creato al passo precedente. il File deve essere Base64 encoded. Le linee di header/footer non sono necessarie e vanno rimosse |
HSM type | Luna or YubiKey |
Richiesta EV Code Signing Certificate
Analogamente ai certificati Document Signing, i certificati Code Signing EV devono essere ordinati su un token USB preconfigurato da Sectigo.
I costi dei token USB non sono coperti dal servizio TCS e sono a carico del richiedente.
Per fare un ordine collegarsi a: https://www.sectigo.com/ssl-certificates-tls/code-signing e usare il codice sconto: 3GE5YPN6T8
Gestione Organizzazione
Modifica della configurazione dell'Organizzazione
Dal menù principale selezionare Organizations. Nella lista selezionare la checkbox relativo alla Organization da modificare.
Si aprirà una finestra laterale composta dalle seguenti sezioni: Certificate Settings, Domains, Email Template, Access Control List, EV Details.
Per poter richiedere certificati IGTF (grid) è necessario modificare (scrivendo un ticket a <garr-ca@garr.it>) il campo "Secondary Organization Name" prestando attenzione che contenga solo caratteri ASCII e che sia identico al campo O eventualmente usato in precedenza per i certificati grid con Digicert (in caso di dubbio consultare il portale Digicert per controllo). Dato che il subject dei certificati grid è usato come "username" è fondamentale che questo rimanga inalterato per non causare problemi di accesso alla grid per gli utenti.
Gli elementi contenuti in Certificate Settings permettono di personalizzare la configurazione ed in particolare nella sezione SSL Certificate è possibile configurare l'accesso via API (Web API) ed eventualmente configurare come obbligatorio un External Requester.
La sezione Self Enrollment non è più parte della configurazione dell'Organizzazione. Vedere la sezione Richiesta certificati SSL tramite codice o autenticazione SAML.
Aggiunta e configurazione Department
Se necessario è possibile suddividere una Organizzazione in Dipartimenti con lo scopo di creare sotto-strutture che in autonomia possano gestire le richieste di certificati su determinati sotto-domini. Gli amministratori di tali sotto-strutture (DRAO) hanno poteri limitati al Dipartimento a cui sono assegnati e sui domini delegati a tale dipartimento. Per delegare un dominio ad un dipartimento seguire la sezione "Gestione domini"
Dal menù principale scegliere Organizations. Nella tabella selezionare la checkbox relativa alla Organization su cui operare e premere il bottone [(+) Add Department].
Si aprirà una finestra pop-up (Departments) che permette di aggiungere nuovi dipartimenti, visualizzare e modificare i dipartimenti già creati.
Aggiungere un nuovo Dipartimento
Premendo il bottone [(+) Add Department] si aprirà un'ulteriore finestra di pop-up (Add New Department) composta da due pagine: una prima parte con le generalità del Department e una seconda con le sezioni Client Certificate, SSL Certificate, Code Signing Certificate.
In General è possibile assegnare il nome al nuovo Department.
In SSL Certificate è possibile configurare l'accesso via API (Web API) ed eventualmente configurare come obbligatorio un External Requester.
La sezione Self Enrollment non è più parte della configurazione del Department. Vedere la sezione Richiesta certificati SSL tramite codice o autenticazione SAML.
In Client Certificate disabilitare la checkbox Allow Key Recovery by Master Administrators.
In Code Signing Certificate è possibile abilitare tale tipo di certificato per questo Department se necessario.
Premere [Save] per salvare la configurazione del nuovo Department.
Visualizzare e modificare i dipartimenti già creati
I Department già creati sono visualizzati. a partire dalla Organization, a cascata premendo il simbolo [>]. Selezionando la checkbox relativa al Department che si vuole visualizzare sarà possibile modificarlo, rimuoverlo definitivamente (simbolo del Cestino), aggiungere e consultare i domini delegati (Domains).
Per la gestione dei domini associati ad un Department fare riferimento alla sezione Gestione Dominii.
Aggiunta e configurazione DRAO
Prima di poter aggiungere un ruolo DRAO è necessario aver creato almeno un Department.
Possono aggiungere e modificare DRAO in un determinato Department tutti i ruoli RAO e i DRAO di quel Department .
Per aggiungere un amministratore DRAO seguire le istruzioni di creazione di un amministratore RAO eseguendo la seguente variazione per la sezione Role:
ROLE
Dopo aver premuto su Expand All selezionare la checkbox indicante il Department opportuno che si trova sotto a:
+ DRAO Admin - SSL
+ DRAO Admin - Client Certificate
+ DRAO Admin - Code Signing
E' possibile assegnare ad un DRAO tutti e 3 i ruoli oppure un sottoinsieme a seconda delle necessità. La configurazione può essere cambiata successivamente.
Per modificare un amministratore già creato in precedenza selezionare dalla tabella degli amministratori la radio button relativa e premere il bottone [Edit].
La maschera di modifica di un amministratore (Edit Client Admin) è sostanzialmente identica alla maschera di creazione nuovo amministratore.
La differenza riguarda la sezione della password in cui è presente il link Reset password.
Reset della password
Il reset della password di un account DRAO può essere fatto da qualsiasi DRAO dello stesso Department e dai RAO della stessa Organization. Dal menù Admins selezionare il nome dell'amministratore da modificare, premere il bottone [Edit] e seguire il link Reset password. La nuova password dovrà essere comunicata out-of-band al collega.
Configurazione SAML
Il portale SCM è disponibile in eduGAIN ed è accessibile tramite tutti gli Identity Provider della Federazione IDEM che sono pubblicati in eduGAIN e consumano correttamente i metadata di federazione (vedi Metadata).
Accesso al portale SCM per RAO e richiesta certificati SSL
Le organizzazioni che intendono abilitare il proprio Identity Provider per l'accesso al portale SCM devono rilasciare i seguenti attributi al Service Provider di Sectigo (entityID = https://cert-manager.com/shibboleth
):
- eduPersonPrincipalName
- displayName (facoltativo)
- givenName (facoltativo)
- sn (facoltativo)
Per verificare che il vostro Identity Provider stia rilasciando correttamente gli attributi necessari, Sectigo mette a disposizione una pagina di controllo al seguente indirizzo:
https://cert-manager.com/customer/garr/ssocheck/.
Una volta configurato e verificato il rilascio degli attributi, l'accesso federato via SAML andrà abilitato nelle sezioni del portale SCM che lo prevedono (ad esempio per IdP Person Id e per il Self Enrollment via SAML).
Accesso al portale self-service via SAML per richiesta Client certificate
Le organizzazioni che intendono abilitare il proprio Identity Provider anche per la richiesta dei client certificate tramite il portale self-service via SAML (https://cert-manager.com/customer/garr/idp/clientgeant) devono rilasciare i seguenti attributi al Service Provider di Sectigo (entityID = https://cert-manager.com/shibboleth
):
- eduPersonPrincipalName (urn:oid:1.3.6.1.4.1.5923.1.1.1.6)
- email (urn:oid:0.9.2342.19200300.100.1.3)
- displayName (urn:oid:2.16.840.1.113730.3.1.241)
- givenName (urn:oid:2.5.4.42)
- sn (urn:oid:2.5.4.4)
- cn (urn:oid:2.5.4.3)
- schacHomeOrganization (urn:oid:1.3.6.1.4.1.25178.1.2.9) con valore pari al "Academic code (SCHAC Home Organization)" impostato in SCM
- eduPersonEntitlement (urn:oid:1.3.6.1.4.1.5923.1.1.1.7) con valore
urn:mace:terena.org:tcs:personal-user
Di seguito un esempio di configurazione per Shibboleth Identity Provider >= 3.2.0:
<AttributeFilterPolicy id="GARR-TCS-4">
<PolicyRequirementRule xsi:type="Requester" value="https://cert-manager.com/shibboleth"/>
<AttributeRule attributeID="eduPersonPrincipalName">
<PermitValueRule xsi:type="ANY"/>
</AttributeRule>
<AttributeRule attributeID="email">
<PermitValueRule xsi:type="ANY"/>
</AttributeRule>
<AttributeRule attributeID="displayName">
<PermitValueRule xsi:type="ANY"/>
</AttributeRule>
<AttributeRule attributeID="givenName">
<PermitValueRule xsi:type="ANY"/>
</AttributeRule>
<AttributeRule attributeID="surname">
<PermitValueRule xsi:type="ANY"/>
</AttributeRule>
<AttributeRule attributeID="commonName">
<PermitValueRule xsi:type="ANY"/>
</AttributeRule>
<AttributeRule attributeID="schacHomeOrganization">
<PermitValueRule xsi:type="ANY"/>
</AttributeRule>
<AttributeRule attributeID="eduPersonEntitlement">
<PermitValueRule xsi:type="ValueRegex" regex="^urn:mace:terena.org:tcs:.*$" />
</AttributeRule>
</AttributeFilterPolicy>
e un esempio di configurazione per Shibboleth Identity Provider < 3.2.0:
<AttributeFilterPolicy id="GARR-TCS-4">
<PolicyRequirementRule xsi:type="basic:AttributeRequesterString" value="https://cert-manager.com/shibboleth"/>
<AttributeRule attributeID="eduPersonPrincipalName">
<PermitValueRule xsi:type="basic:ANY"/>
</AttributeRule>
<AttributeRule attributeID="email">
<PermitValueRule xsi:type="basic:ANY"/>
</AttributeRule>
<AttributeRule attributeID="displayName">
<PermitValueRule xsi:type="basic:ANY"/>
</AttributeRule>
<AttributeRule attributeID="givenName">
<PermitValueRule xsi:type="basic:ANY"/>
</AttributeRule>
<AttributeRule attributeID="surname">
<PermitValueRule xsi:type="basic:ANY"/>
</AttributeRule>
<AttributeRule attributeID="commonName">
<PermitValueRule xsi:type="basic:ANY"/>
</AttributeRule>
<AttributeRule attributeID="schacHomeOrganization">
<PermitValueRule xsi:type="basic:ANY"/>
</AttributeRule>
<AttributeRule attributeID="eduPersonEntitlement">
<PermitValueRule xsi:type="basic:AttributeValueRegex" regex="^urn:mace:terena.org:tcs:.*$" />
</AttributeRule>
</AttributeFilterPolicy>
Per verificare il rilascio attributi al portale self-service SAML accedere, dopo l'autenticazione, a https://cert-manager.com/Shibboleth.sso/Session
ACME e gestione automatizzata dei certificati SSL
Tempo di Lettura: 20 minuti
Attenzione: a partire dalla data del 18 Marzo 2022, in cui è avvenuta la migrazione del portale SCM, gli account ACME creati in precedenza non sono più funzionanti e pertanto è necessario crearne di nuovi.
Il protocollo ACME, Automated Certificate Management Environment, è uno standard IETF (RFC 8555) per la gestione automatizzata dei certificati X.509.
Il protocollo ACME è stato implementato per la prima volta da Let's Encrypt, la Certification Authority libera e gratuita gestita dal Internet Security Research Group (ISRG). E' bene ricordare che se da una parte Let's Encrypt fornisce un servizio formidabile, dall'altra supporta solo i certificati di tipo DV.
Il client di riferimento per l'uso di Let's Encrypt e del protocollo ACME è certbot ed è l'unico attualmente supportato da Sectigo, almeno in forma ufficiale.
Sectigo supporta il protocollo ACME e certbot per le operazioni principali di gestione dei certificati: creazione, rinnovo e revoca.
Riferimenti
- RFC 8555: https://tools.ietf.org/html/rfc8555
- Let's Encrypt: https://letsencrypt.org
- Certbot, il client ACME raccomandato:A https://certbot.eff.org
- Supporto ACME in Sectigo: vedi il capitolo "Using the Sectigo ACME Service" della guida SCM - Sectigo Certificate Manager Administrator's Guide/
Installazione di certbot
Per l'installazione di certbot è caldamente consigliato seguire sempre le istruzioni ufficiali disponibili su https://certbot.eff.org. Qualora nel menù a tendina "system" non sia presente il S.O. in uso consigliamo di eseguire l'installazione via pip. Riportiamo qui le istruzioni per l'installazione di certbot via pip, per maggiori informazioni vi consigliamo di consultare le istruzioni ufficiali e più recenti su https://certbot.eff.org.
- SSH into the server
Tutti i comandi che seguono devono essere eseguiti da root o con sudo. Accedere con ssh al server in cui gira il server HTTP oppure nel sistema in cui si vuole generare il certificato.
- Install system dependencies
Le dipendenze di sistema includono generalmente Python 3.6+, il modulo venv e il plug-in Augeas per Apache.
In caso di problemi nell'installazione dei moduli di crittografia potrebbe essere necessario installare dipendenze addizionali. Per maggiori informazioni vedere cryptography project's site.
I comandi per installare le dipendenze sulla macchina sono i seguenti:
Per distribuzioni APT-based(e.g. Debian, Ubuntu ...):
sudo apt update sudo apt install python3 python3-venv libaugeas0
Per distribuzioni RPM-based (e.g. Fedora, CentOS ...):
sudo dnf install python3 augeas-libs
- Remove certbot-auto and any Certbot OS packages
Se sono presenti pacchetti Certbot installati utilizzando un gestore di pacchetti del sistema operativo come apt, dnf o yum, è necessario rimuoverli prima di installare lo snap Certbot per garantire che quando si esegue il comando certbot venga utilizzato lo snap anziché l'installazione dal pacchetto del sistema operativo manager. Il comando esatto per eseguire questa operazione dipende dal sistema operativo, ma sono esempi comuni sudo apt-get remove certbot
, sudo dnf remove certbot
, o sudo yum remove certbot
.
- Set up a Python virtual environment
Eseguire le seguenti istruzioni sulla riga di comando sulla macchina per configurare un ambiente virtuale.
sudo python3 -m venv /opt/certbot/ sudo /opt/certbot/bin/pip install --upgrade pip
- Install Certbot
Eseguire questo comando sulla riga di comando sulla macchina per installare Certbot.
sudo /opt/certbot/bin/pip install certbot certbot-apache
- Prepare the Certbot command
Eseguire le seguenti istruzioni sulla riga di comando sulla macchina per garantire che il comando certbot possa essere eseguito.
sudo ln -s /opt/certbot/bin/certbot /usr/bin/certbot
- Set up automatic renewal
Eseguire la riga seguente, che aggiungerà un processo cron al crontab predefinito.
echo "0 0,12 * * * root /opt/certbot/bin/python -c 'import random; import time; time.sleep(random.random() * 3600)' && sudo certbot renew -q" | sudo tee -a /etc/crontab > /dev/null
- [Monthly] Upgrade certbot
È importante fare l'upgrade periodico di Certbot per mantenerlo aggiornato. Per fare ciò, eseguire il comando seguente sulla riga di comando della macchina.
sudo /opt/certbot/bin/pip install --upgrade certbot certbot-apache
Se questo passaggio genera errori, eseguire sudo rm -rf /opt/certbot
e ripetere tutte le istruzioni di installazione dall'inizio.
(Sectigo) Creazione account ACME in SCM
Per poter iniziare ad utilizzare ACME con Sectigo è necessario creare uno o più account ACME per la propria organizzazione.
Accedere a SCM con un account RAO (o DRAO, assicurandosi che la delega dei domini al Department sia stata preventivamente effettuata da un RAO) e dal menù principale selezionare Enrollment > ACME.
Workaround: se gli endpoint per ACME non fossero disponibili agire nella sezione Filter eseguendo i seguenti passaggi:
- dal menù Add Filter → Select Type
- dal menù Type → scegliere Public ACME CA
Nota importante: l'endpoint DV, anche se presente nell'elenco, non è compreso nel contratto TCS e non è utilizzabile.
Dall'elenco di endpoint (in seguito riferiti come ACME URL) selezionare uno tra https://acme.sectigo.com/v2/OV
e https://acme.sectigo.com/v2/GEANTOV
se volete creare un account ACME per certificati OV, o uno tra https://acme.sectigo.com/v2/EV
e https://acme.sectigo.com/v2/GEANTEV
per certificati EV e poi premere il bottone [Accounts]. Nella finestra che si aprirà premere il bottone verde [+] per aggiungere un nuovo account. Nella finestra di creazione dell'account è necessario:
- inserire il nome del account nel campo Name.
- scegliere la Organization dal menù a tendina (nella maggior parte dei casi ci sarà una sola organizzazione e tutto sarà già selezionato).
- scegliere eventualmente il Department.
- nella sezione DOMAINS scegliere con il (+) i dominii per cui abilitare questo account e premere il tasto [Save]. La lista dei domini è modificabile anche in seguito, vedere più sotto. Includere sempre anche il dominio nella versione *. altrimenti l'account non sarà in grado di funzionare correttamente (esempio
subdomain.domain.org
e*.subdomain.domain.org
odomain.org
e*.domain.org
se si vuole chiedere un certificato perwww.subdomain.domain.org
).
L'account verrà creato immediatamente e verranno visualizzati a video i dati del nuovo che dovranno essere copiati:
- ACME URL
- Account ID
- Key ID
- HMAC Key
IMPORTANTE Key ID e HMAC Key sono le credenziali dell'account ACME appena creato e dalla release SCM 22.1 il portale Sectigo SCM le mostrerà nella sezione Details. Questo significa che i parametri possono essere riutilizzati per registrare l'account ACME su più server.
Una volta creato l'account e visualizzate le credenziali, l'interfaccia ritornerà sull'elenco degli account ACME disponibili per l'organizzazione (dipartimento nel caso di un DRAO), dove l'account appena creato sarà inizialmente in stato pending. Non c'è da preoccuparsi: l'account è già operativo e può essere già utilizzato.
L'account creato è di tipo EAB (External Account Binding), ed i certificati relativi saranno classificati in SCM con status External. Inoltre le Certification Authority intermedie per i certificati emessi tramite ACME sono diverse da quelle utilizzate per i certificati emessi tramite SCM o tramite le API di Sectigo. Ad esempio per i certificati di tipo OV avremo la CA intermedia Sectigo RSA Organization Validation Secure Server CA invece che GÉANT OV RSA CA 4. Ovviamente dal punto di vista funzionale non c'è alcuna differenza.
Per modificare l'elenco dei domini associati ad un account ACME selezionare dall'elenco degli account quello desiderato e selezionare il bottone [Edit]. Nella finestra successiva sarà possibile agire nella sezione DOMAINS e modificare i domini con (+).
Per visualizzare l'elenco dei Client su cui è stato registrato l'account ACME selezionare dall'elenco degli account quello desiderato e selezionare il bottone [Clients]. Nella finestra successiva sarà possibile vedere le informazioni sui Client (bottone [Details]) e rimuoverli singolarmente.
(Sectigo) Registrazione account ACME in certbot, emissione, rinnovo automatico e revoca dei certificati
Registrazione in certbot di un account creato in SCM
Tutti i comandi che seguono devono essere eseguiti da root o con sudo.
Prima di cominciare a gestire i certificati è necessario registrare il nostro account Sectigo ACME con il comando che segue:
certbot register --email <EMAIL> --server <ACME URL> --eab-kid <KEY ID> --eab-hmac-key <HMAC KEY>
Sostituire <KEY ID>, <HMAC KEY> e <ACME URL> con i corrispondenti valori che vi si siete segnati durante la creazione dell'account ACME su SCM.
Il processo di registrazione comporta l'accettazione dei Terms of Service; vi verrà inoltre richiesto se volete condividere la mail con la Electronic Frontier Foundation.
Il risultato sarà la creazione dell'account e della relativa chiave nella directory /etc/letsencrypt/accounts
.
IMPORTANTE Non è possibile registrare due account ACME di Sectigo sullo stesso client. E' possibile avere più account ACME registrati sullo stesso client a patto che siano di due Certification Autority differenti. Prima di registrare un nuovo account ACME della stessa CA occorre rimuovere il precedente.
Validazione dei dominii
certbot supporta anche la validazione dei dominii tramite .well-known path, ma dato che gli account ACME/Sectigo sono legati ad una ben definita ORG i cui dominii sono già stati creati e validati su SCM, non è richiesto fare alcuna validazione dei domini via certbot.
Assicurarsi che i domini associati all'account ACME siano validati ("Validated" con etichetta verde). La procedura è quella indicata più sopra "Gestione Dominii" -> "Validazione dominio" e la rivalidazione deve avvenire annualmente. ACME non può rilasciare certificati per domini non validati.
Emissione dei certificati
certbot permette di creare ed installare automaticamente i certificati dei virtual host presenti e correttamente configurati sul nostro server web, o semplicemente di creare i certificati senza installazione automatica.
Con il comando run
si creano ed installano chiave e certificato per il virtualhost <FQDN-certificato>
(sostituire <ACME URL>
con il corrispondente valore presente nell'account ACME su SCM):
certbot run --apache --email <EMAIL> --server <ACME URL> --domain <FQDN-certificato> --key-type rsa --rsa-key-size 3072 --cert-name <FRIENDLY-NAME>
oppure per chiavi ECC
certbot run --apache --email <EMAIL> --server <ACME URL> --domain <FQDN-certificato> --key-type ecdsa --elliptic-curve secp384r1 --cert-name <FRIENDLY-NAME>
Le modalità di installazione possono variare a seconda delle distribuzioni, ma in generale certbot, una volta creati chiave e certificato, tenterà di individuare la configurazione del virtualhost apache corrispondente e di modificarla per farla puntare al certificato ed alla chiave appena creati.
Per limitarsi alla sola creazione del certificato e della relativa in formato PEM, utilizzare invece il comando certonly
con l'opzione --standalone
(sostituire <ACME URL>
con il corrispondente valore presente nell'account ACME su SCM):
certbot certonly --standalone --email <EMAIL> --server <ACME URL> --domain <FQDN-certificato> --key-type rsa --rsa-key-size 3072 --cert-name <FRIENDLY-NAME>
oppure per chiavi ECC
certbot certonly --standalone --email <EMAIL> --server <ACME URL> --domain <FQDN-certificato> --key-type ecdsa --elliptic-curve secp384r1 --cert-name <FRIENDLY-NAME>
Per richiedere un certificato con SAN multipli, quindi per più nomi di dominio, ripetere l'opzione --domain DOMINIO
o utilizzare una lista di nomi di dominio separata da virgola, ma senza spazi, come da esempio (sostituire <ACME URL>
con il corrispondente valore presente nell'account ACME su SCM):
certbot certonly --standalone --email <EMAIL> --server <ACME URL> --domain <FQDN-certificato1>,<FQDN-certificato2>,<FQDN-certificato2> --key-type rsa --rsa-key-size 3072 --cert-name <FRIENDLY-NAME>
oppure per chiavi ECC
certbot certonly --standalone --email <EMAIL> --server <ACME URL> --domain <FQDN-certificato1>,<FQDN-certificato2>,<FQDN-certificato2> --key-type ecdsa --elliptic-curve secp384r1 --cert-name <FRIENDLY-NAME>
Alcune opzioni utili in fase di creazione dei certificati:
--quiet
silenzia il comando, utile per automation
--non-intereactive
utile per automation, ma necessita di ulteriori opzioni--key-type
permette di scegliere il tipo di chiave {rsa,ecdsa}
--rsa-key-size BITS
per specificare la grandezza della chiave RSA in bits, il default è 2048--elliptic-curve N
per specificare la lunghezza della chiave ECC in bits, il default è secp256r1
Tutti i certificati creati vengono salvati in /etc/letsencrypt/archive/<DOMAIN>
e collegati in /etc/letsencrypt/live/<DOMAIN>
se attivi. Inoltre le chiavi private sono salvate come privkey.pem
.
Importante: assicurarsi di configurare il rinnovo automatico del certificato. Molti dei pacchetti di installazione di certbot includono già una configurazione di base per il rinnovo dei certificati via cron. In generale conviene sempre fare riferimento alle "Certbot instructions / Set up automatic renewal" presenti nel sito https://certbot.eff.org/instructions relative al software e al sistema prescelto.
Revoca dei certificati
Per revocare i certificati emessi utilizzare il comando revoke
(sostituire <ACME URL>
con il corrispondente valore presente nell'account ACME su SCM):
certbot revoke --email <EMAIL> --server <ACME URL> --cert-name <FQDN-certificato>
Nel caso di certificati per più nomi di dominio, basterà specificare uno dei nomi validi. Inoltre tramite l'opzione --cert-path
è possibile utilizzare il percorso del certificato al posto del nome di dominio:
certbot revoke --email <EMAIL> --server <ACME URL> --cert-path /etc/letsencrypt/live/<FQDN-certificato>/cert.pem
Rinnovo automatico e forzato dei certificati
La semplicità con cui è possibile rinnovare i certificati è molto probabilmente il maggior punto di forza di ACME e certbot.
Il rinnovo avviene con il comando renew
e rinnova automaticamente tutti i certificati presenti in /etc/letsencrypt
e che stanno per scadere entro 30 giorni:
certbot renew
Ci sono una serie di opzioni utili per il rinnovo dei certificati che è bene conoscere:
--quiet
silenzia il comando, utile per richiamare il rinnovo da cron.--force-renewal
forza il rinnovo di tutti i certificati indipendentemente dalla loro data di scadenza.--reuse-key
rinnova solo il certificato, ma non emette anche una nuova chiave (default false).
Molti dei pacchetti di installazione di certbot includono già una configurazione di base per il rinnovo dei certificati via cron. Ad esempio su Debian 10 il pacchetto certbot installa il seguente cron job in /etc/cron.d/certbot
:
# /etc/cron.d/certbot: crontab entries for the certbot package # # Upstream recommends attempting renewal twice a day # # Eventually, this will be an opportunity to validate certificates # haven't been revoked, etc. Renewal will only occur if expiration # is within 30 days. # # Important Note! This cronjob will NOT be executed if you are # running systemd as your init system. If you are running systemd, # the cronjob.timer function takes precedence over this cronjob. For # more details, see the systemd.timer manpage, or use systemctl show # certbot.timer. SHELL=/bin/sh PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin 0 */12 * * * root test -x /usr/bin/certbot -a \! -d /run/systemd/system && perl -e 'sleep int(rand(43200))' && certbot -q renew
E' anche possibile forzare il rinnovo del certificato di un solo dominio utilizzando il comando certonly e le opportune opzioni. Ad esempio per forzare il rinnovo del nome di dominio <FQDN-certificato1>
, riutilizzando la chiave esistente (sostituire <ACME URL>
con il corrispondente valore presente nell'account ACME su SCM):
certbot certonly --standalone --force-renewal --reuse-key --agree-tos --email <EMAIL> --server <ACME URL> --domain <FQDN-certificato1>
Utilizzo di un account ACME su più server
Per utilizzare certbot su più server avete le seguenti opzioni:
- creare un account ACME su SCM per ogni server da abilitare e registrarlo seguendo le istruzioni "Registrazione account ACME e uso di certbot".
- registrare un account ACME esistente su più server seguendo le istruzioni "Registrazione account ACME e uso di certbot".
- copiare le chiavi di uno degli account ACME già registrati in ogni server che si desidera abilitare trasferendo tutto il contenuto della directory
/etc/letsencrypt/accounts
presente sul primo server su cui è stata effettuata la registrazione.
La seconda opzione dovrebbe essere la più conveniente nella maggior parte delle situazioni perché permette di tener traccia dei client su cui è stata effettuata la registrazione dell'account ACME (vedere l'apposita sezione in SCM).
(Let's encrypt) emissione, rinnovo automatico e revoca dei certificati
Tutti i comandi devono essere eseguiti da root o con sudo accedendo con ssh al server in cui gira il server HTTP.
Per l'installazione di certbot e la richiesta di certificati con Let's encrypt è caldamente consigliato seguire sempre le istruzioni ufficiali disponibili su https://certbot.eff.org. Qualora nel menù a tendina "system" non sia presente il S.O. in uso consigliamo di eseguire l'installazione via pip. Per maggiori informazioni vi consigliamo di consultare le istruzioni ufficiali e più recenti su https://certbot.eff.org.
Esempio di link per la combinazione "Apache" + "pip": https://certbot.eff.org/instructions?ws=apache&os=pip
IMPORTANTE: seguire esattamente tutti i passi indicati dalla guida di certbot.
Ogni istanza del client certbot permette la registrazione di un solo account per Certification Authority ma anche la registrazione di un secondo account se proveniente da una Certification Authority diversa.
E' dunque possibile registrare contemporaneamente nella stessa istanza di certbot sia un account Sectigo che uno Let's encrypt.
Quali account sono registrati in un'istanza di certbot
Tramite i seguenti comandi si può scoprire se un'instanza di certbot ha già degli account associati:
certbot show_account
(Let’s encrypt)certbot show_account --server https://acme.sectigo.com/v2/OV
(Sectigo OV)certbot show_account --server https://acme.sectigo.com/v2/GEANTOV
(Sectigo GEANTOV)
Il web server deve essere raggiungibile
Prima di poter richiedere un certificato con Let's encrypt assicurarsi che il fqdn del server sia raggiungibile via web.
In caso negativo non sarà possibile procedere con la richiesta di certificato usando le istruzioni seguenti. Fare riferimento alla documentazione di certbot per tutte le altre casistiche.
Richiedere e installare in automatico un certificato
Lanciare il seguente comando per richiedere un certificato ed installarlo su Apache:
sudo certbot --apache
o su Nginx:
sudo certbot --nginx
Richiedere un certificato senza installazione automatica
Per richiedere un certificato in maniera più conservativa senza installazione su Apache:
sudo certbot certonly --apache
o per Nginx
sudo certbot certonly --nginx
Installare manualmente il certificato tramite i file di configurazione del server web.
Consultare la lista dei certificati gestiti dal client certbot
Lanciare il comando:
certbot certificates
oppure consultare il contenuto delle cartelle /etc/letsencrypt/{live,archive}
Revocare un certificato
Con certbot esistono due modalità per revocare un certificato: tramite opzione cert-name
e indicando direttamente il percorso del file.
certbot revoke --cert-name example.com
certbot revoke --cert-path /etc/letsencrypt/live/example.com/cert.pem
Completata la revoca certbot chiederà se si desidera cancellare i certificati appena revocati. Se i certificati revocati non sono stati cancellati certbot proverà a rinnovarli durante il prossimo rinnovo automatico.
Consultazione certificati
Per consultare la situazione dei certificati emessi accedere al sito:
https://crt.sh/
seguendo le istruzioni di ricerca fornite dal sito stesso.