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:
- La TS-CNS (Tessera Sanitaria - Carta Nazionale Servizi), rilasciata dalla regione di appartenenza;
- 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 ;-)
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.
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:
- il nome del file che contiene il certificato pubblico del server in formato PEM;
- 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 \
&& 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/
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à:
- abilita il modulo SSL
- abilita il modulo headers
- abilita il site ssl di default con la configurazione per la TS-CNS e CIE
- abilita delle opzioni di configurazione al fine di rafforzare la sicurezza SSL/TLS
- 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.
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.
OCSP ha alcuni vantaggi rispetto alle CRL:
- Elimina la necessità per i client di scaricare e analizzare le liste di revoca.
- Provvede a un migliore utilizzo della banda: dal momento che un messaggio OCSP ha una dimensione trascurabile rispetto alle CRL.
- 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.
- OCSP è più efficiente delle CRL e quindi scala in modo migliore.
OCSP ha anche alcuni punti sfavorevoli rispetto alle CRL:
- Per ogni revoca è necessario fare una richiesta al responder, se il responder non risponde entro un timeout OCSP verrà ignorato silenziosamente.
- 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.
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:
- certs
- contiene il certificato del server (chiave pubblica e chiave privata);
- httpd: contiene tutte le configurazioni di Apache necessarie per attivare l'autenticazione tramite la Smart Card TS-CNS e CIE;
- www: contiene la piccolissima applicazione di test;
- scripts: contiene gli scripts di aggiornamento certificati e abiliatazione del servizio cron
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.0Una 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.0Utilizzando 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-cnsNel 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:latestA 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.
Puntando all'indirizzo https://entra-cns-cie.dontesta.it:10443/ dovrebbe accadere quanto segue:
- Richiesta del PIN CODE della vostra TS-CNS o CIE;
- Richiesta di selezione del vostro certificato digitale;
- 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:
- CNS identificata dall'OID 1.3.76.16.2.1;
- 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
...
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:
- build: Target di default che esegue il build dell'immagine;
- debug: Esegue la build dell'immagine e successivamente apre un shell bash sul container;
- run: Esegue la build dell'immagine e successivamente crea il container lanciando l'applicazione (Apache HTTPD 2.4);
- clean: Esegue un prune delle immagini;
- remove: Rimuove l'ultima immagine creata;
- 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.
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.
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.