cie-cns-apache-docker

Apache HTTP 2.4 per Smart Card TS-CNS (Tessera Sanitaria - Carta Nazionale Servizi) e CIE (Carta d’Identità Elettronica)

L’obiettivo di questo progetto è quello di fornire un template pronto all’uso che realizza un sistema di autenticazione tramite la Smart Card TS-CNS (o CNS) e la CIE (Carta d’Identità Elettronica) basato su Apache HTTP. Ognuno può poi modificare o specializzare questo progetto sulla base delle proprie esigenze

Si tratta di un progetto docker per la creazione di un container che implementa un sistema di mutua autenticazione o autenticazione bilaterale SSL/TLS. Questo meccanismo di autenticazione richiede anche il certificato digitale da parte del client, certificato che in questo caso risiede all’interno della TS-CNS o della CIE.

La particolarità del sistema implementato (attraverso questo container) è quella di consentire l’autenticazione tramite:

1. La TS-CNS (Tessera Sanitaria - Carta Nazionale Servizi), rilasciata dalla regione di appartenenza;
2. La CIE (Carta d’Identità Elettronica), rilasciata dal comune di residenza.

Per la Regione Lazio il portale di riferimento per la TS-CNS è https://cns.regione.lazio.it/. Ogni regione ha il proprio portale dedicato alla TS-CNS dov’è possibile trovare tutte le informazioni utili.

La maggior parte dei comuni d’Italia è abilitato al rilascio della CIE. La pagina La Carta d’identità elettronica nei Comuni d’Italia del Ministero dell’Interno mostra il dettaglio di quali sono i comuni abilitati.

Sul sito dell’Agenzia per l’Italia digitale (AgID) nella sezione Piattaforme/Carta Nazionale Servizi, sono disponibili tutti i documenti tecnici da consultare per eventuali approfondimenti.

Sul sito del Ministero dell’Interno dedicato alla CIE, il documento Carta d’Identità Elettronica CIE 3.0 descrive la CIE dal punto di vista prettamente tecnico e in modo approfondito.

Se vuoi conoscere di più sul progetto, invito a leggere l’articolo Cos’è il progetto CIE/CNS Apache Docker

Sei impaziente? Bene, allora potresti provare con Play-With-Docker ;-)

1 - Overview

Questo container parte dall’immagine base di ubuntu:22.04, poi specializzato al fine di soddisfare i requisiti minimi per un sistema di autenticazione basato sulla TS-CNS.

Il software di base installato è:

• Apache HTTP 2.4 (2.4.51)
• PHP 8 (8.0.8)
• Modulo PHP per Apache

L’installazione di PHP e del modulo per Apache è del tutto opzionale. I due moduli sono stati installati esclusivamente per costruire la pagina di atterraggio dell’utente dopo la fase di autenticazione. Questa pagina mostra le informazioni estratte dal certificato digitale.

2 - Struttura del Docker File

Cerchiamo di capire quali sono le sezioni più significative del Dockefile. La prima riga del file (come anticipato in precedenza) fa in modo che il container parta dall’immagine docker ubuntu:22.04.

FROM ubuntu:22.04

A seguire c’è la sezione delle variabili di ambiente che sono prettamente specifiche di Apache HTTP. I valori di queste variabili d’ambiente possono essere modificate in base alle proprie esigenze.

# Apache ENVs
ENV APACHE_SERVER_NAME entra-cns-cie.dontesta.it
ENV APACHE_SERVER_ADMIN [email protected]
ENV APACHE_SSL_CERTS entra-cns-cie.dontesta.it_crt.pem
ENV APACHE_SSL_PRIVATE entra-cns-cie.dontesta.it_key.pem
ENV APACHE_SSL_PORT 10443
ENV APACHE_LOG_LEVEL info
ENV APACHE_SSL_LOG_LEVEL info
ENV APACHE_SSL_VERIFY_CLIENT optional
ENV APPLICATION_URL https://${APACHE_SERVER_NAME}:${APACHE_SSL_PORT}
ENV CLIENT_VERIFY_LANDING_PAGE /error.php

Le prime due variabili sono molto esplicative, la prima in particolare, imposta il server name, che in questo caso è: entra-cns-cie.dontesta.it.

Le due variabili APACHE_SSL_CERTS e APACHE_SSL_PRIVATE impostano:

1. il nome del file che contiene il certificato pubblico del server in formato PEM;
2. il nome del file che contiene la chiave privata (in formato PEM) del certificato pubblico.

Il certificato utilizzato in questo progetto è stato rilasciato da ZeroSSL RSA Domain Secure Site CA e richiesto tramite il servizio offerto da ZeroSSL.

Il CN di questo specifico certificato è impostato a entra-cns-cie.dontesta.it. La scadenza prevista per questo certificato è il 03 novembre 2021.

Di default la porta HTTPS è impostata a 10443 dalla variabile APACHE_SSL_PORT. La variabile APPLICATION_URL definisce il path di redirect qualora si accedesse via protocollo HTTP e non HTTPS.

Le variabili APACHE_LOG_LEVELe APACHE_SSL_LOG_LEVEL, consentono di modificare il livello log generale e quello specifico per il modulo SSL. Il valore di default è impostato a INFO. Per maggiori informazioni potete consultare la documentazione su LogLevel Directive.

La variabile APACHE_SSL_VERIFY_CLIENT agisce sulla configurazione del processo di verifica del certificato lato client. Il valore di default è impostato a optional. Rendere opzionale la verifica, consente una gestione più flessibile dell’errore in caso che la validazione fallisse.

Nel caso in cui il valore della direttiva di Apache SSLVerifyClient sia optional o optional_no_ca, in caso di errore viene visualizzata una specifica pagina di errore definita dalla variabile CLIENT_VERIFY_LANDING_PAGE.

A seguire c’è la sezione delle variabili di ambiente che sono prettamente specifiche per lo script di download dei certificati pubblici degli enti. Questi enti, sono autorizzati dallo stato Italiano al rilascio di certificati digitali per il cittadino e le aziende.

La variabile d’ambiente GOV_TRUST_CERTS_SERVICE_TYPE_IDENTIFIER applica il filtro sul Service Type Identifier, il cui valore assunto nel caso della CNS e CIE è http://uri.etsi.org/TrstSvc/Svctype/IdV

# Env for Trusted CA certificate
ENV GOV_TRUST_CERTS_OUTPUT_PATH /tmp/gov/trust/certs
ENV GOV_TRUST_CERTS_SERVICE_TYPE_IDENTIFIER http://uri.etsi.org/TrstSvc/Svctype/IdV

A seguire un estratto dalla Trust Service Status List dov’è riportato il valore dell’elemento ServiceTypeIdentifier.

<ServiceInformation>
<ServiceTypeIdentifier>http://uri.etsi.org/TrstSvc/Svctype/IdV</ServiceTypeIdentifier>
<ServiceName>
<Name xml:lang="en">CN=Provincia autonoma Bolzano - CA Cittadini, OU=Servizi di Certificazione, O=Actalis S.p.A., C=IT</Name>
</ServiceName>
<ServiceDigitalIdentity>
<DigitalId>
<X509Certificate>...</X509Certificate>
</DigitalId>
</ServiceDigitalIdentity>
<ServiceStatus>http://uri.etsi.org/TrstSvc/TrustedList/Svcstatus/recognisedatnationallevel</ServiceStatus>
<StatusStartingTime>2016-06-30T22:00:00Z</StatusStartingTime>
</ServiceInformation>

La sezione a seguire del Dockerfile, contiene tutte le direttive necessarie per l’installazione del software indicato in precedenza. Dato che la distribuzione scelta è Ubuntu, il comando apt è responsabile della gestione dei package, quindi dell’installazione.

# Install services, packages and do cleanup
RUN apt update \
    && apt install -y apache2 \
    && apt install -y ca-certificates \
    && apt install -y php libapache2-mod-php \
    && apt install -y python3 \
    && apt install -y cron \
    && apt install -y pip \
    && pip install lxml \
    && pip install cryptography \
    && rm -rf /var/lib/apt/lists/*

L’installazione di Python è necessaria per eseguire lo script parse-gov-certs.py responsabile del download di tutti i certificati pubblici degli enti che sono autorizzati dallo stato Italiano al rilascio di certificati digitali per il cittadino e le aziende.

Il punto di distribuzione dei certificati (chiamato Trust Service Status List) è gestito dall’Agenzia per l’Italia Digitale o AgID e raggiungibile al seguente URL https://eidas.agid.gov.it/TL/TSL-IT.xml

# Download Trusted CA certificate and copy to ssl system path
RUN /usr/local/bin/parse-gov-certs.py \
        --output-folder ${GOV_TRUST_CERTS_OUTPUT_PATH} \
        --service-type-identifier ${GOV_TRUST_CERTS_SERVICE_TYPE_IDENTIFIER} \
    && cp ${GOV_TRUST_CERTS_OUTPUT_PATH}/*.pem /etc/ssl/certs/

Attenzione: dalla release 2.3.0 del progetto, è stata introdotta sullo script parse-gov-certs.py la funzionalità di controllo scadenza validità dei certificati. Per impostazione predefinita, lo script non salva i certificati scaduti e scrive un messaggio del tipo Skipping expired certificate. Qualora si vogliano salvare i certificati scaduti, è possibile utilizzare l’opzione --save-expired-certs e in questo caso lo script salverà i certificati scaduti con il suffisso _expired e scriverà un messaggio del tipo Added certificate: expired....

La sezione a seguire del Dockerfile, anch’essa esplicativa, copia le configurazioni di Apache opportunamente modificate al fine di abilitare la mutua autenticazione.

# Copy Apache configuration file
COPY configs/httpd/default-ssl.conf /etc/apache2/sites-available/
COPY configs/httpd/ssl-params.conf /etc/apache2/conf-available/
COPY configs/httpd/dir.conf /etc/apache2/mods-enabled/
COPY configs/httpd/ports.conf /etc/apache2/

La sezione a seguire del Dockerfile, copia il certificato pubblico e la relativa chiave privata.

# Copy Server (pub and key) entra-cns-cie.dontesta.it
COPY configs/certs/*_crt.pem /etc/ssl/certs/
COPY configs/certs/*_ca_bundle.pem /etc/ssl/certs/
COPY configs/certs/*_key.pem /etc/ssl/private/

La sezione a seguire del Dockerfile, copia una semplice applicazione a scopo di test sulla document root standard di Apache.

# Copy php samples script and other
COPY configs/www/*.php /var/www/html/
COPY configs/www/bootstrap-italia /var/www/html/bootstrap-italia
COPY configs/www/css /var/www/html/css
COPY configs/www/img /var/www/html/img
COPY configs/www/js /var/www/html/js
COPY configs/www/secure /var/www/html/secure

La sezione a seguire del Dockerfile, copia gli script necessari attivare il cron e consentire l’aggiornamento dei certificati della CNS una volta al giorno.

# Copy auto-update-gov-certificates scripts and entrypoint
COPY scripts/auto-update-gov-certificates /auto-update-gov-certificates
COPY scripts/entrypoint /entrypoint

La sezione a seguire del Dockerfile, esegue una serie di comandi con l’obiettivo finale di abilitare l’aggiornamento dei certificati della CNS e CIE.

# Set execute flag for entrypoint and crontab entry
# Add Cron entry auto-update-gov-certificates
# Create Project ENV for crontab
RUN chmod +x /entrypoint \
    && chmod +x /auto-update-gov-certificates \
    && echo "30 23 * * * root . /project_env.sh; /auto-update-gov-certificates >> /var/log/cron.log 2>&1" > /etc/cron.d/auto-update-gov-certificates \
    && printenv | sed 's/^\(.*\)$/export \1/g' | grep -E "APACHE_|APPLICATION_URL|GOV_" > /project_env.sh \
    && chmod +x /project_env.sh

L’aggiornamento dei certificati avviene una volta al giorno alle ore 23:30. L’esecuzione dello script di aggiornamento produce i due file di log cron.log e auto-update-gov-certificates.log. Entrambe i file di log risiedono all’interno del folder /var/log.

La sezione a seguire del Dockerfile esegue le seguenti attività:

1. abilita il modulo SSL
2. abilita il modulo headers
3. abilita il site ssl di default con la configurazione per la TS-CNS e CIE
4. abilita delle opzioni di configurazione al fine di rafforzare la sicurezza SSL/TLS
5. esegue il re-hash dei certificati. Operazione necessaria affinché Apache sia in grado di leggere i nuovi certificati

RUN a2enmod ssl \
    && a2enmod headers \
    && a2enmod rewrite \
    && a2ensite default-ssl \
    && a2enconf ssl-params \
    && c_rehash /etc/ssl/certs/

Le due ultime direttive indicate sul Dockerfile, dichiarano la porta HTTPS (APACHE_SSL_PORT) che deve essere pubblicata e il comando da eseguire per mettere in listen (o ascolto) il nuovo servizio Apache HTTP.

3 - Qualche nota su OCSP

Il protocollo OCSP (Online Certificate Status Protocol) definito dall’RFC 2560 è un meccanismo per determinare se un certificato del server è stato revocato o meno. Questo protocollo è stato creato in alternativa al CRL (Certificate Revocation List)

L’OCSP Stapling è una “forma speciale” di protocollo, in cui il server, mantiene le risposte OCSP correnti per i suoi certificati e li invia ai client che comunicano con il server.

La maggior parte dei certificati contiene l’indirizzo di un risponditore OCSP gestito dall’autorità di certificazione emittente, mod_ssl può comunicare con tale risponditore per ottenere una risposta firmata che può essere inviata ai client che comunicano con il server.

Poiché il client può ottenere lo stato di revoca del certificato dal server, senza richiedere una connessione aggiuntiva dal client all’autorità di certificazione, il metodo OCSP Stapling, è il modo preferito per ottenere lo stato di revoca.

Altri vantaggi dell’eliminazione della comunicazione tra i client e l’autorità di certificazione sono che la cronologia di navigazione del client non è esposta all’autorità di certificazione e lo stato di ottenimento è più affidabile non dipendendo da server di autorità di certificazione potenzialmente pesantemente caricati.

Poiché la risposta ottenuta dal server può essere riutilizzata per tutti i client che utilizzano lo stesso certificato durante il tempo in cui la risposta è valida, il sovraccarico per il server è minimo.

Una volta che il supporto SSL è stato configurato correttamente, abilitare l’OCSP Stapling generalmente richiede solo modifiche molto minori alla configurazione httpd.

A seguire la configurazione dell’OCSP Stapling applicata in questo progetto.

SSLUseStapling on
SSLStaplingCache "shmcb:logs/stapling-cache(150000)"

È possibile utilizzare due metodi per verificare se l’OCSP Stapling funziona: utilizzando il comando openssl e il test SSL su Qualys.

echo QUIT | openssl s_client -connect entra-cns-cie.dontesta.it:443 -status 2> /dev/null | grep -A 17 'OCSP response:' | grep -B 17 'Next Update'

Risposta OCSP per il certificato del server entra-cns-cie.dontesta.it

OCSP response:
======================================
OCSP Response Data:
    OCSP Response Status: successful (0x0)
    Response Type: Basic OCSP Response
    Version: 1 (0x0)
    Responder Id: C8D97868A2D91968D53D72DE5F0A3EDCB58686A6
    Produced At: Aug  7 05:34:48 2021 GMT
    Responses:
    Certificate ID:
      Hash Algorithm: sha1
      Issuer Name Hash: 082E3FF9058CFE8A7C18BD13EFDF1D1660707A6B
      Issuer Key Hash: C8D97868A2D91968D53D72DE5F0A3EDCB58686A6
      Serial Number: 42F5FA2D3D023DEDD74CC743E7657B69
    Cert Status: good
    This Update: Aug  7 05:34:48 2021 GMT
    Next Update: Aug 14 05:34:48 2021 GMT

A seguire l’estratto del test eseguito su https://entra-cns-cie.dontesta.it tramite SSL Labs Qualys dove si evidenzia l’abilitazione dell’OCSP Stapling.

Evidenza dell’abilitazione dell’OCSP Stapling

Il protocollo CRL richiede al browser di scaricare quantità potenzialmente elevate di’informazioni di revoca del certificato SSL: numeri di serie del certificato e stato dell’ultima data di pubblicazione di ciascun certificato. Il problema con il protocollo CRL è che può aumentare il tempo impiegato per completare la negoziazione SSL.

- Vantaggi

OCSP ha alcuni vantaggi rispetto alle CRL:

1. Elimina la necessità per i client di scaricare e analizzare le liste di revoca.
2. Provvede a un migliore utilizzo della banda: dal momento che un messaggio OCSP ha una dimensione trascurabile rispetto alle CRL.
3. Supporta una catena fidata di OCSP richiesta tra i vari responder. Questo permette ai clienti di comunicare con un responder fidato per interrogare un altro responder.
4. OCSP è più efficiente delle CRL e quindi scala in modo migliore.

- Svantaggi

OCSP ha anche alcuni punti sfavorevoli rispetto alle CRL:

1. Per ogni revoca è necessario fare una richiesta al responder, se il responder non risponde entro un timeout OCSP verrà ignorato silenziosamente.
2. Ogni richiesta deve essere analizzata dal responder, di fatto si passa la cronologia di navigazione al responder, questo è un evidente problema di privacy.

Consiglio la lettura della documentazione su OCSP Stapling per maggiori informazioni sulla configurazione e le pratiche migliori d’utilizzo.

4 - Organizzazione

In termini di directory e file, il progetto è organizzato così come mostrato a seguire. Il cuore di tutto è il folder configs.

├── Dockerfile
├── configs
│    ├── certs
│    │   ├── entra-cns-cie.dontesta.it_crt.pem
│    │   └── entra-cns-cie.dontesta.it_key.pem
│    ├── httpd
│    │   ├── 000-default.conf
│    │   ├── default-ssl.conf
│    │   ├── dir.conf
│    │   ├── ports.conf
│    │   └── ssl-params.conf
│    └── wwww
└── scripts
    ├── auto-update-gov-certificates
    ├── parse-gov-certs.py
    └── entrypoint

Il folder configs contiene al suo interno altri folder e file, in particolare:

1. certs
   • contiene il certificato del server (chiave pubblica e chiave privata);
2. httpd: contiene tutte le configurazioni di Apache necessarie per attivare l’autenticazione tramite la Smart Card TS-CNS e CIE;
3. www: contiene la piccolissima applicazione di test;
4. scripts: contiene gli scripts di aggiornamento certificati e abiliatazione del servizio cron

5 - Quickstart

L’immagine di questo progetto docker è disponibile sull’account docker hub italia/cie-cns-apache-docker.

A seguire il comando per il pull dell’immagine docker su docker hub. Il primo comando esegue il pull dell’ultima versione (tag latest), mentre il secondo comando esegue il pull della specifica versione dell’immagine, in questo caso la versione 2.1.0.

docker pull italia/cie-cns-apache-docker
docker pull italia/cie-cns-apache-docker:2.1.0

Una volta eseguito il pull dell’immagine docker (versione 2.1.0) è possibile creare il nuovo container tramite il comando a seguire. È possibile utilizzare la porta HTTPS standard (443) se libera e se in ogni caso le policy del sistema operativo ne consentano l’uso.

# Run del container per l'ultima versione dell'immagine
docker run -i -t -d -p 443:10443 --name=cie-cns italia/cie-cns-apache-docker

# Run del container per l'immagine versione 2.1.0
docker run -i -t -d -p 10443:10443 --name=cie-cns italia/cie-cns-apache-docker:2.1.0

# Per usare la porta standard HTTPS fare il mount della directory locale dove
# risiedono le pagine dell'applicazione d'esempio.
docker run -i -t -d -p 443:10443 --name=cie-cns --mount type=bind,source="$(pwd)"/configs/www,destination=/var/www/html,consistency=cached italia/cie-cns-apache-docker:2.1.0

Utilizzando il comando docker ps dovremmo poter vedere in lista il nuovo container, così come indicato a seguire.

CONTAINER ID        IMAGE                                  COMMAND                  CREATED             STATUS              PORTS                      NAMES
bb707fb00e89        italia/cie-cns-apache-docker:2.1.0   "/usr/sbin/apache2ct…"   6 seconds ago       Up 4 seconds        0.0.0.0:10443->10443/tcp   cie-cns

Nel caso in cui vogliate apportare delle modifiche, dovreste poi procedere con la build della nuova immagine e al termine di questa lanciare l’immagine ottenuta. A seguire sono indicati i comandi docker da eseguire dal proprio terminale.

I comandi docker di build e run devono essere lanciati dalla root della directory di progetto dopo aver fatto il clone di questo repository.

docker build -t cie-cns-apache-docker .
docker run -i -t -d -p 10443:10443 --name=cie-cns cie-cns-apache-docker:latest

A questo punto sul nostro sistema dovremmo avere la nuova immagine con il nome cie-cns-apache-docker e in esecuzione il nuovo container chiamato cie-cns.

Utilizzando il comando docker images dovremmo poter vedere in lista la nuova immagine, così come indicato a seguire.

REPOSITORY                                      TAG                 IMAGE ID            CREATED             SIZE
cie-cns-apache-docker                           latest              1a145475d1f1        30 minutes ago      208MB

Utilizzando il comando docker ps dovremmo poter vedere in lista il nuovo container con le modifiche apportate, così come indicato a seguire.

CONTAINER ID        IMAGE                          COMMAND                  CREATED             STATUS              PORTS                      NAMES
65c874216624        cie-cns-apache-docker:latest   "/usr/sbin/apache2ct…"   36 minutes ago      Up 36 minutes       0.0.0.0:10443->10443/tcp   cie-cns

Da questo momento è possibile raggiungere il servizio di autenticazione basato sulla TS-CNS e CIE utilizzando il browser.

Per evitare l’errore SSL_ERROR_BAD_CERT_DOMAIN da parte del browser, raggiungendo il servizio tramite la URL https://127.0.0.1:10443/, bisogna aggiungere al proprio file di hosts la riga a seguire.

##
# Servizio di autenticazione via TS-CNS
##
127.0.0.1       entra-cns-cie.dontesta.it

In ambiente di collaudo e/o produzione il nome del servizio o FQDN sarà registrato su un DNS.

Lato server-side è tutto pronto, non resta fare altro che un test. Nel caso disponiate di una vostra Smart Card TS-CNS o CIE e il vostro PC già configurato per l’utilizzo, potreste eseguire da subito un test puntando il vostro browser alla URL https://entra-cns-cie.dontesta.it:10443/.

Riguardo il lettore di Smart Card, personalmente utilizzo due modelli prodotti da Bit4id per i quali non ho riscontrato problemi di compatibilità con i più diffusi sistemi operativi.

1. miniLector CIE
2. miniLector CIE Datasheet
3. miniLector EVO
4. miniLector EVO Datasheet

Puntando all’indirizzo https://entra-cns-cie.dontesta.it:10443/ dovrebbe accadere quanto segue:

1. Richiesta del PIN CODE della vostra TS-CNS o CIE;
2. Richiesta di selezione del vostro certificato digitale;
3. Visualizzazione della pagina di benvenuto.

Oltre a verificare che il certificato digitale sulla CNS e CIE sia valido, è anche eseguito il controllo per cui tra le Certificate Policies (Object ID: 2.5.29.32) ci sia quella specifica della CNS e CIE. Certification Policies:

1. CNS identificata dall’OID 1.3.76.16.2.1;
2. CIE identificata dall’OID 1.3.76.47.4

Questo check è demandato allo script PHP configs/www/secure/certificate_policy_check.php mostrato di seguito.

<?php
$cnsCertificatePolicies = 'Policy: 1.3.76.16.2.1';
$cieCertificatePolicies = 'Policy: 1.3.76.47.4';

$ssl = openssl_x509_parse(getenv('SSL_CLIENT_CERT'));

if((preg_match("/$cnsCertificatePolicies$/m", $ssl['extensions']['certificatePolicies']) == 0) && 
    (preg_match("/$cieCertificatePolicies$/m", $ssl['extensions']['certificatePolicies']) == 0)) {
    
    die("Il certificato è valido ma non dispone della Certification Policy 
        che dovrebbe avere una CNS - Carta Nazionale Servizi o la CIE - Carta d'Identità Elettronica. 
        <br>La Certification Policy per la CNS è definita dall'OID 1.3.76.16.2.1 mentre per la CIE
        è definita dall'OID 1.3.76.47.4.

        <ul>
            <li>OID 1.3.76.16.2.1 => <a href='http://oid-info.com/cgi-bin/display?oid=1.3.76.16.2.1&action=display'
                >{iso(1) identified-organization(3) uninfo(76) agid(16) authentication(2) cns(1)}
                </a>
            </li>
            <li>OID 1.3.76.47.4 => <a href='http://oid-info.com/get/1.3.76.47'
                >{iso(1) identified-organization(3) uninfo(76) 47}
                </a>
            </li>
        </ul>");
}
?>

Purtroppo la funzione PeerExtList(object-ID) del modulo mod_ssl non permette il check dell’estensione CertificatePolicies perché strutturata.

A seguire una serie di screenshot che mostrano l’esecuzione del test di autenticazione, utilizzando la TS-CNS. L’esecuzione del test di autenticazione con la CIE è esattamente identico a quello della TS-CNS.

Figura 1 - Inserimento del PIN della TS-CNS

Figura 2 - Selezione del certificato digitale

Figura 3 - Pagina di benvenuto dopo l’autenticazione

Figura 4 - Visualizzazione del certificato pubblico in formato strutturato

Figura 5 - Visualizzazione del certificato pubblico in formato x509 PEM

Figura 6 - Notifica di errore per check Policy fallito

Figura 7 - Pagina di errore in caso di errore validazione certificato

Figura 8 - Richiesta PIN della CIE

Figura 9 - Pagina di benvenuto dopo autenticazione via CIE

Accedendo agli access log di Apache è possibile notare queste due informazioni utili al tracciamento delle operazioni eseguite dall’utente:

• Il protocollo SSL
• Il SSL_CLIENT_S_DN_CN

172.17.0.1 TLSv1.2 - MSRNTN77H15C351X/6120016461039008.i1ZpZfaCX/eKyikBfnF8to+M2T8= [18/Dec/2018:17:48:53 +0000] "GET / HTTP/1.1" 200 2787 "-" "Mozilla/5.0 (Macintosh; Intel Mac OSX 10.14; rv:64.0) Gecko/20100101 Firefox/64.0"

Il valore di SSL_CLIENT_S_DN_CN è inoltre impostato come SSLUserName, questo fa in modo che la variabile REMOTE_USER sia impostata con il CN del certificato digitale che identifica univocamente l’utente.

...
SSLVerifyClient ${APACHE_SSL_VERIFY_CLIENT}
SSLVerifyDepth  5

SSLUserName SSL_CLIENT_S_DN_CN
...

6 - Build, Run e Push docker image via Makefile

Al fine di semplificare le operazioni di build, run e push dell’immagine docker, è stato introdotto il Makefile sulla versione 1.2.3 del progetto.

Per utilizzare il Makefile, occorre che sulla propria macchina siano installati correttamente i tools di build.

I target disponibili sono i seguenti:

1. build: Target di default che esegue il build dell’immagine;
2. debug: Esegue la build dell’immagine e successivamente apre un shell bash sul container;
3. run: Esegue la build dell’immagine e successivamente crea il container lanciando l’applicazione (Apache HTTPD 2.4);
4. clean: Esegue un prune delle immagini;
5. remove: Rimuove l’ultima immagine creata;
6. release: Esegue la build dell’imaggine e successivamente effettua il push su dockerhub.

É possibile eseguire il target release solo sul branch master, inoltre, il push dell’immagine su DockerHub richiede l’accesso (via username e password) tramite il comando docker login.

7 - Conclusioni

Lo stimolo iniziale che ha poi scatenato la nascita di questo progetto, arriva dalle difficoltà incontrate cercando di accedere ai servizi del Sistema Informativo Veterinario utilizzando la mia TS-CNS su Mac OS.

Credo che questo progetto possa essere utile a coloro che hanno la necessità di realizzare un servizio di autenticazione basato sulla TS-CNS o CIE e non sanno magari da dove iniziare. Questo progetto potrebbe essere quindi un buon punto di partenza.

Ogni suggerimento e/o segnalazione di bug è gradito; consiglio eventualmente di aprire una issue

Ho descritto la mia esperienza con il Sistema Informativo Veterinario sull’articolo Come accedere al portale VETINFO tramite TS-CNS e Mac OS pubblicato recentemente su Antonio Musarra’s Blog.

Project License

The MIT License (MIT)

Copyright © 2024 Antonio Musarra’s Blog - https://www.dontesta.it, [email protected]

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.