{"id":16998482,"url":"https://github.com/amusarra/docker-apache-ssl-tls-mutual-authentication","last_synced_at":"2025-04-12T06:07:18.390Z","repository":{"id":144585921,"uuid":"180888951","full_name":"amusarra/docker-apache-ssl-tls-mutual-authentication","owner":"amusarra","description":"L'obiettivo di questo progetto è quello di fornire un template pronto all'uso e che realizza un sistema di mutua autenticazione o autenticazione bilaterale SSL/TLS  basato su Apache HTTP","archived":false,"fork":false,"pushed_at":"2023-05-01T20:39:08.000Z","size":13702,"stargazers_count":4,"open_issues_count":3,"forks_count":1,"subscribers_count":2,"default_branch":"master","last_synced_at":"2025-04-12T06:07:10.401Z","etag":null,"topics":["apache2","authentication","mutual-authentication","ssl","tls"],"latest_commit_sha":null,"homepage":"http://bit.ly/2Sm5dU7","language":"CSS","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/amusarra.png","metadata":{"files":{"readme":"README.markdown","changelog":"CHANGELOG.md","contributing":null,"funding":null,"license":"LICENSE.md","code_of_conduct":"CODE_OF_CONDUCT.md","threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null}},"created_at":"2019-04-11T22:41:35.000Z","updated_at":"2024-01-15T00:21:43.000Z","dependencies_parsed_at":"2023-03-29T12:51:33.698Z","dependency_job_id":"99796318-52e1-4e3b-bf4e-96ec124a7b4b","html_url":"https://github.com/amusarra/docker-apache-ssl-tls-mutual-authentication","commit_stats":null,"previous_names":[],"tags_count":12,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/amusarra%2Fdocker-apache-ssl-tls-mutual-authentication","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/amusarra%2Fdocker-apache-ssl-tls-mutual-authentication/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/amusarra%2Fdocker-apache-ssl-tls-mutual-authentication/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/amusarra%2Fdocker-apache-ssl-tls-mutual-authentication/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/amusarra","download_url":"https://codeload.github.com/amusarra/docker-apache-ssl-tls-mutual-authentication/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":248525144,"owners_count":21118618,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["apache2","authentication","mutual-authentication","ssl","tls"],"created_at":"2024-10-14T04:05:23.458Z","updated_at":"2025-04-12T06:07:18.364Z","avatar_url":"https://github.com/amusarra.png","language":"CSS","funding_links":[],"categories":[],"sub_categories":[],"readme":"# Apache HTTP 2.4 - Docker image for SSL/TLS Mutual Authentication\n[![Antonio Musarra's Blog](https://img.shields.io/badge/maintainer-Antonio_Musarra's_Blog-purple.svg?colorB=6e60cc)](https://www.dontesta.it)\n[![Build Status](https://travis-ci.org/amusarra/docker-apache-ssl-tls-mutual-authentication.svg?branch=master)](https://travis-ci.org/amusarra/docker-apache-ssl-tls-mutual-authentication)\n[![Twitter Follow](https://img.shields.io/twitter/follow/antonio_musarra.svg?style=social\u0026label=%40antonio_musarra%20on%20Twitter\u0026style=plastic)](https://twitter.com/antonio_musarra)\n\nL'obiettivo di questo progetto è quello di fornire un **template** pronto all'uso\ne che realizza un sistema di **mutua autenticazione o autenticazione bilaterale SSL/TLS** \nbasato su [Apache HTTP](http://httpd.apache.org/docs/2.4/). \n**Ognuno è libero poi di modificare o specializzare questo progetto sulla base delle proprie esigenze**\n\nSe sei impaziente allora potresti provare con Play-With-Docker\n\n[![Try in PWD](https://raw.githubusercontent.com/play-with-docker/stacks/master/assets/images/button.png)](https://labs.play-with-docker.com/?stack=https://raw.githubusercontent.com/amusarra/docker-apache-ssl-tls-mutual-authentication/master/docker-compose.yml)\n\n\n![](images/iconfinder_note.png)\nIl progetto è stato realizzato su macOS Mojave 10.14.4 e testato su Docker Desktop \nCE (versione 2.0.0.3) e Docker (Engine) 18.09.2. Per l'installazione su ambienti\nMicrosoft Windows consiglio la lettura di [Install Docker Desktop for Windows](https://docs.docker.com/docker-for-windows/install/).\n\n## 1 - Overview\nQuesto è un progetto [docker](https://www.docker.com/) che parte dall'immagine \nbase di [*ubuntu:20.04*](https://hub.docker.com/_/ubuntu), specializzato per \nsoddisfare i requisiti minimi per un sistema di mutua autenticazione SSL/TLS.\n\nIl software di base installato è:\n\n* Apache HTTP 2.4 (2.4.41-1ubuntu1)\n* PHP 7.4\n* PHP 7.4 FPM (FastCGI Process Manager)\n\n_L'installazione di PHP e del modulo per Apache è del tutto opzionale_. I due \nmoduli sono stati installati esclusivamente per costruire la pagina di atterraggio\ndell'utente dopo la fase di autenticazione. Questa pagina mostra una serie \nd'informazioni base estratte dal certificato digitale utilizzato per \nl'autenticazione.\n\nLa mutua autenticazione basata sul protocollo SSL/TLS si riferisce a due parti \nche si autenticano reciprocamente attraverso la verifica del certificato \ndigitale fornito in modo che entrambe i partecipanti siano sicuri \ndell'identità altrui.\n\nDa un punto di vista di alto livello, il processo di autenticazione e creazione \ndi un canale crittografato utilizzando l'autenticazione reciproca (o mutua \nautenticazione) basata su certificati prevede i passaggi seguenti:\n\n1. Un client richiede l'accesso a una risorsa protetta;\n2. Il server presenta il suo certificato al client;\n3. Il client verifica il certificato del server;\n4. Se ha successo, il client invia il suo certificato al server;\n5. Il server verifica le credenziali del cliente;\n6. In caso di esito positivo, il server concede l'accesso alla risorsa protetta richiesta dal client.\n\nIn Figura 1 è mostrato quello che accade durante il processo di autenticazione \nreciproca (o mutua autenticazione).\n\n![Cosa succede durante il processo di autenticazione reciproca](images/security-sslBMAWithCertificates.gif)\n\n**Figura 1 - Cosa succede durante il processo di autenticazione reciproca (immagine da https://docs.oracle.com)**\n\n\n## 2 - Struttura del Docker File\nCerchiamo di capire quali sono le sezioni più significative del Dockerfile. \nLa prima riga del file (come anticipato in precedenza) fa in modo che il \ncontainer parta dall'immagine docker *ubuntu:20.04*.\n\n```docker\nFROM ubuntu:20.04\n```\n\nA seguire c'è la sezione delle variabili di ambiente che sono prettamente \nspecifiche di Apache HTTP. I valori di queste variabili d'ambiente possono\nessere modificate in base alle proprie esigenze.\n\n```docker\n# General Apache ENVs\nENV APACHE_RUN_USER www-data\nENV APACHE_RUN_GROUP www-data\nENV APACHE_SERVER_NAME tls-auth.dontesta.it\nENV APACHE_SERVER_ADMIN tls-auth@dontesta.it\nENV APACHE_SSL_CERTS tls-auth.dontesta.it.cer \nENV APACHE_SSL_PRIVATE tls-auth.dontesta.it.key\nENV APACHE_SSL_PORT 10443\nENV APACHE_LOG_LEVEL info\nENV APACHE_SSL_LOG_LEVEL info\nENV APACHE_SSL_VERIFY_CLIENT optional\nENV APACHE_SSL_SSL_PROXY_ENGINE Off\nENV APACHE_SSL_PROXY_CHECK_PEER_NAME On\nENV APACHE_SERVER_SIGNATURE Off\nENV APACHE_SERVER_TOKENS Prod\nENV APACHE_HTTP_HEADER_X_POWERED_BY \"Apache HTTP 2.4 for SSL/TLS Mutual Authentication (Ver. ${VERSION} - Git URL: ${VCS_URL} - Git Ref: ${VCS_REF})\"\n\n# For more info See https://httpd.apache.org/docs/2.4/mod/mod_http2.html\nENV APACHE_HTTP_PROTOCOLS http/1.1\n\n# Specifics env Apache for application \nENV APPLICATION_URL https://${APACHE_SERVER_NAME}:${APACHE_SSL_PORT}\nENV CLIENT_VERIFY_LANDING_PAGE /error.php\n\n# Reverse Proxy Application\nENV APACHE_PROXY_PRESERVE_HOST On\nENV API_BASE_PATH /secure/api\nENV API_BACKEND_BASE_URL http://127.0.0.1:8000${API_BASE_PATH}\n```\n\nIl primo gruppo di quattro variabili sono molto esplicative e non necessitano \napprofondimenti. Le variabili a seguire e in particolare \n`APACHE_SSL_CERTS` e `APACHE_SSL_PRIVATE` impostano:\n\n1. il nome del file che contiene il certificato pubblico del server in formato PEM;\n2. il nome del file che contiene la chiave privata (in formato PEM) del certificato pubblico.\n\nIl certificato server utilizzato in questo progetto è stato rilasciato da una\n_Certification Authority_ privata create ad hoc e ovviamente non riconosciuta. \nIl CN (Common Name) di questo specifico certificato è impostato \na **tls-auth.dontesta.it** rilasciato dalla _Antonio Musarra's Blog Certification Authority_.\n\nDi default la porta *HTTPS* è impostata a **10443** dalla variabile `APACHE_SSL_PORT`.\nLa variabile `APPLICATION_URL` definisce il path di redirect qualora si accedesse \nvia protocollo HTTP e non HTTPS.\n\nLe variabili `APACHE_LOG_LEVEL`e `APACHE_SSL_LOG_LEVEL`, consentono di modificare\nil livello log generale e quello specifico per il modulo SSL. Il valore di default\nè impostato a INFO. Per maggiori informazioni potete consultare la documentazione su\n[LogLevel Directive](https://httpd.apache.org/docs/2.4/mod/core.html#loglevel).\n\nLa variabile `APACHE_SSL_VERIFY_CLIENT` agisce sulla configurazione del processo\ndi verifica del certificato lato client. Il valore di default è impostato a **optional**.\nRendere opzionale la verifica, consente una gestione più flessibile dell'errore \nin caso che la validazione del certificato client fallisse.\n\nNel caso in cui il valore della direttiva di Apache **SSLVerifyClient** sia \n**optional** o **optional_no_ca**, se dovesse accadere qualche errore di validazione,\nallora sarebbe visualizzata la specifica pagina definita dalla variabile \n`CLIENT_VERIFY_LANDING_PAGE`.\n\nLa variabile `APACHE_HTTP_PROTOCOLS` specifica l'elenco di protocolli supportati \nper il server/host virtuale. L'elenco determina i protocolli consentiti che un \ncliente può negoziare per questo server/host.\n\nÈ necessario impostare i protocolli se si desidera estendere i protocolli \ndisponibili per un server/host. Per impostazione predefinita, è consentito solo \nil protocollo **http/1.1** (che include la compatibilità con i client 1.0 e 0.9).\n\nI protocolli validi sono http/1.1 per le connessioni **http** e **https**, \n**h2** sulle connessioni https e **h2c** per le connessioni http.\n\nPer maggiorni informazioni consultare la documentazione \n[Apache Module mod_http2](https://httpd.apache.org/docs/2.4/mod/mod_http2.html).\n\nLa sezione a seguire del Dockerfile contiene tutte le direttive necessarie per \nl'installazione del software indicato in precedenza. Dato che la distribuzione scelta \nè [**Ubuntu**](https://www.ubuntu.com/), il comando *apt* è responsabile della gestione \ndei package, quindi dell'installazione.\n\n```docker\n# Install services, packages and do cleanup\nRUN apt update \\\n    \u0026\u0026 apt install -y apache2 \\\n    \u0026\u0026 apt install -y php php7.4-fpm \\\n    \u0026\u0026 apt install -y curl \\\n    \u0026\u0026 apt install -y python3-pip \\\n    \u0026\u0026 apt install -y git \\\n    \u0026\u0026 rm -rf /var/lib/apt/lists/*\n```\n \nLa sezione a seguire del Dockerfile, anch'essa esplicativa, copia le \nconfigurazioni di Apache opportunamente modificate al fine di abilitare \nla mutua autenticazione.\n\n```docker\n# Copy Apache configuration file\nCOPY configs/httpd/000-default.conf /etc/apache2/sites-available/\nCOPY configs/httpd/default-ssl.conf /etc/apache2/sites-available/\nCOPY configs/httpd/ssl-params.conf /etc/apache2/conf-available/\nCOPY configs/httpd/dir.conf /etc/apache2/mods-enabled/\nCOPY configs/httpd/ports.conf /etc/apache2/\n```\n\nLa sezione a seguire del Dockerfile, copia la coppia di chiavi del server \ne il certificato pubblico della CA.\n\n```docker\n# Copy Server (pub and key) tls-auth.dontesta.it\n# Copy CA (Certification Authority) Public Key\nCOPY configs/certs/blog.dontesta.it.ca.cer /etc/ssl/certs/\nCOPY configs/certs/tls-auth.dontesta.it.cer /etc/ssl/certs/\nCOPY configs/certs/tls-auth.dontesta.it.key /etc/ssl/private/\n``` \n\nLa sezione a seguire del Dockerfile, copia tre script PHP a scopo di test sulla \n*document root* standard di Apache.\n\n```docker\n# Copy php samples script and other\nCOPY configs/www/*.php /var/www/html/\nCOPY configs/www/assets /var/www/html/assets\nCOPY configs/www/secure /var/www/html/secure\nCOPY images/favicon.ico /var/www/html/favicon.ico\n```\n\nLa sezione a seguire del Dockerfile copia lo script di entrypoint che avvia\nserver Apache HTTP.\n\n```docker\n# Copy scripts and entrypoint\nCOPY scripts/entrypoint /entrypoint\n```\n\nLa sezione a seguire del Dockerfile esegue le seguenti principali attività:\n\n1. abilita il modulo SSL\n2. abilita il modulo headers\n3. abilita il modulo MPM Worker\n4. abilita il modulo HTTP2\n5. abilita i moduli Proxy, Proxy HTTP e Proxy FCGI (Fast CGI) \n6. abilita il site ssl di default con la configurazione per la mutua autenticazione\n7. abilita delle opzioni di configurazione al fine di rafforzare la sicurezza SSL/TLS\n8. esegue il re-hash dei certificati. Operazione necessaria affinché Apache sia in grado di leggere i nuovi certificati\n\n```docker\nRUN a2enmod ssl \\\n    \u0026\u0026 a2enmod headers \\\n    \u0026\u0026 a2enmod rewrite \\\n    \u0026\u0026 a2dismod mpm_prefork \\\n    \u0026\u0026 a2dismod mpm_event \\\n    \u0026\u0026 a2enmod mpm_worker \\\n    \u0026\u0026 a2enmod proxy_fcgi \\\n    \u0026\u0026 a2enmod http2 \\\n    \u0026\u0026 a2enmod proxy \\\n    \u0026\u0026 a2enmod proxy_http \\\n    \u0026\u0026 a2enmod remoteip \\\n    \u0026\u0026 a2ensite default-ssl \\\n    \u0026\u0026 a2enconf ssl-params \\\n    \u0026\u0026 a2enconf php7.4-fpm \\\n    \u0026\u0026 c_rehash /etc/ssl/certs/\n```\n\nLe due ultime direttive indicate sul Dockerfile, dichiarano la porta HTTPS \n(`APACHE_SSL_PORT`) che deve essere pubblicata e il comando da eseguire per mettere \nin listen (o ascolto) il nuovo servizio Apache HTTP.\n\n## 3 - Organizzazione\nIn termini di directory e file, il progetto è organizzato così come mostrato a \nseguire. Il cuore di tutto è la directory **configs**.\n\n```\n├── Dockerfile\n├── configs\n│    ├── certs\n│    │   ├── blog.dontesta.it.ca.cer\n│    │   ├── blog.dontesta.it.ca.key\n|    |   ├── tls-auth.dontesta.it.cer\n|    |   ├── tls-auth.dontesta.it.key\n|    |   ├── tls-auth.dontesta.it.req\n|    |   ├── tls-client.dontesta.it.cer\n|    |   ├── tls-client.dontesta.it.key\n|    |   ├── tls-client.dontesta.it.p12\n|    |   ├── tls-client.dontesta.it.req\n|    |   ├── mrossi.dontesta.it.cer\n|    |   ├── mrossi.dontesta.it.key\n|    |   ├── mrossi.dontesta.it.p12\n|    |   └── mrossi.dontesta.it.req\n│    ├── httpd\n│    │   ├── 000-default.conf\n│    │   ├── default-ssl.conf\n│    │   ├── dir.conf\n│    │   ├── ports.conf\n│    │   └── ssl-params.conf\n│    ├── openssl\n│    │   └── openssl.cnf\n│    └── wwww\n└── scripts\n    └── entrypoint\n```\n\nLa directory *configs* contiene al suo interno altre folder e file, \nin particolare:\n\n1. **certs**\n    * contiene il certificato del server (chiave pubblica, chiave privata e CSR);\n    * contiene il certificato della CA (chiave pubblica e chiave privata);\n    * contiene il certificato client personale per l'autenticazione tramite browser. Sono disponibili: chiave pubblica, chiave privata, CSR, coppia di chiavi in formato PKCS#12;\n    * contiene il certificato client da utilizzare per autenticare un'applicazione o dispositivo. Sono disponibili: chiave pubblica, chiave privata, CSR, coppia di chiavi in formato PKCS#12;\n2. **openssl**: contiene il file di configurazione per il tool openssl con le impostazioni predefinite;\n3. **httpd**: contiene tutte le configurazioni di Apache necessarie per abilitare la mutua autenticazione;\n4. **www**: contiene una semplice interfaccia web;\n5. **scripts**: contiene l'entrypoint script che avvia il server Apache\n\n## 4 - Quickstart\nL'immagine di questo progetto docker è disponibile sul mio account docker hub\n[amusarra/apache-ssl-tls-mutual-authentication](https://hub.docker.com/r/amusarra/apache-ssl-tls-mutual-authentication).\n\nA seguire il comando per il **pull** dell'immagine docker ospitata su docker hub. \nIl primo comando esegue il pull dell'ultima versione (tag latest), mentre il \nsecondo comando esegue il pull della specifica versione dell'immagine che in \nquesto caso è la versione 1.0.0.\n\n```bash\ndocker pull amusarra/apache-ssl-tls-mutual-authentication\ndocker pull amusarra/apache-ssl-tls-mutual-authentication:1.0.0\n```\nUna volta eseguito il pull dell'immagine docker (versione 1.0.0) è possibile \ncreare il nuovo container tramite il comando a seguire.\n\n```bash\ndocker run -i -t -d -p 10443:10443 --name=apache-ssl-tls-mutual-authentication amusarra/apache-ssl-tls-mutual-authentication:1.0.0\n```\n\nUtilizzando il comando `docker ps` dovremmo poter vedere in lista il nuovo\ncontainer, così come indicato a seguire.\n\n```bash\nCONTAINER ID        IMAGE                                  COMMAND                  CREATED             STATUS              PORTS                      NAMES\nbb707fb00e89        amusarra/apache-ssl-tls-mutual-authentication:1.0.0   \"/usr/sbin/apache2ct…\"   6 seconds ago       Up 4 seconds        0.0.0.0:10443-\u003e10443/tcp   apache-ssl-tls-mutual-authentication\n```\n\nNel caso in cui vogliate apportare delle modifiche al Dockerfile, dovreste poi \nprocedere con la build della nuova immagine e al termine eseguire il run \ndell'immagine ottenuta. A seguire sono indicati i comandi *docker* da eseguire \ndal proprio terminale.\n\n_I comandi docker di build e run devono essere eseguiti dalla root della directory \ndi progetto dopo aver fatto il clone di questo repository._\n\n```bash\ndocker build -t apache-ssl-tls-mutual-authentication .\ndocker run -i -t -d -p 10443:10443 --name=apache-ssl-tls-mutual-authentication apache-ssl-tls-mutual-authentication:latest\n```\n\nA questo punto sul nostro sistema dovremmo avere la nuova immagine con il \nnome **apache-ssl-tls-mutual-authentication** e in esecuzione il nuovo container chiamato\n**apache-ssl-tls-mutual-authentication**. Per ragioni di comodità ho chiamato il container\ncon lo stesso nome dell'immagine, nessuno però vieta di assegnare un nome diverso. \n\nUtilizzando il comando `docker images` dovremmo poter vedere in lista la nuova\nimmagine, così come indicato a seguire.\n\n```\nREPOSITORY                                      TAG                 IMAGE ID            CREATED             SIZE\napache-ssl-tls-mutual-authentication                           latest              1a145475d1f1        30 minutes ago      242MB\n```\n\nUtilizzando il comando `docker ps` dovremmo poter vedere in lista il nuovo\ncontainer, così come indicato a seguire.\n\n```\nCONTAINER ID        IMAGE                          COMMAND                  CREATED             STATUS              PORTS                      NAMES\n65c874216624        apache-ssl-tls-mutual-authentication:latest   \"/usr/sbin/apache2ct…\"   36 minutes ago      Up 36 minutes       0.0.0.0:10443-\u003e10443/tcp   apache-ssl-tls-mutual-authentication\n```\n\nDa questo momento è possibile raggiungere il servizio di mutua autenticazione \nSSL/TLS utilizzando il browser. \n\nPer evitare l'errore `SSL_ERROR_BAD_CERT_DOMAIN` da parte del browser accedendo \nal servizio tramite la URL https://127.0.0.1:10443/, bisogna aggiungere al proprio\nfile di _hosts_ la riga a seguire.\n\n```\n##\n# Servizio di mutua autenticazione via Apache HTTPD\n##\n127.0.0.1       tls-auth.dontesta.it\n```\n\nIn ambiente di collaudo e/o produzione il nome del servizio o FQDN sarà registrato \nsu un DNS.\n\nLato **server-side** è tutto pronto, manca però una configurazione **client side**,\novvero, l'installazione del certificato digitale personale sul proprio browser. All'interno\ndel progetto ho reso disponibili due certificati di esempio che possono essere utilizzati\ncome certificati client, in particolare:\n\n1. mrossi.dontesta.it.p12\n2. tls-client.dontesta.it.p12\n\nIl primo è un certificato digitale _personale_, invece, il secondo certificato digitale può\nessere utilizzato per autenticare un'applicazione. Entrambe i certificati (quindi la coppia \ndi chiavi) sono contenuti all'interno di un PKCS#12. A seguire sono mostrati i subject dei\nrispettivi certificati.\n\nLa password di entrambe i PKCS#12 è impostata a: **secret**. Questa è la password\nda utilizzare per importare i certificati.\n\n```\nSubject: C=IT, L=Rome, ST=Italy, O=Mario Rossi S.r.l, OU=Horse Club, CN=mario.rossi@horseclubsample.com/emailAddress=admin@horseclubsample.com\n\nSubject: C=IT, L=Bronte, ST=Italy, O=Judio Horse Club, OU=IT Services, CN=tls-client.dontesta.it/emailAddress=info@dontesta.it\n```\n\nI due certificati sono stati rilasciati dalla CA **Antonio Musarra's Blog Certification Authority**. \nA seguire i dettagli della CA che ha rilasciato tutti i certificati disponibili\nall'interno del progetto.\n\n```\nIssuer: C=IT, L=Rome, ST=Italy, O=Antonio Musarra's Blog, OU=IT Security Department, CN=Antonio Musarra's Blog Certification Authority/emailAddress=info@dontesta.it\n```\n\nUna volta installato il certificato client (file con estensione .p12) sul proprio \nbrowser (per esempio Firefox), è possibile eseguire il test di mutua autenticazione \ntramite certificato. \n\nLa Figura 2 mostra il certificato digitale installato sul browser Firefox. \nQuesto è il certificato da utilizzare per l'autenticazione.\n\n![Certificato Digitale Personale installato sul browser](images/InstalledDigitalPersonalCertified.png)\n\n**Figura 2 - Installazione del certificato digitale personale sul browser Firefox**\n\nPuntando all'indirizzo [https://tls-auth.dontesta.it:10443](https://tls-auth.dontesta.it:10443) dovrebbe accadere quanto segue:\n\n1. Cliccare sul pulsante _Login_ o _LOGIN WITH YOUR DIGITAL CERTIFICATE_\n2. Selezionare il certificato digitale installato in precedenza\n3. Visualizzazione della pagina di benvenuto.\n\nLe immagini a seguire mostrano il risultato dei tre step precedentemente indicati.\n\n![Welcome Page di Accesso](images/WelcomePageToAccessViaClientCertificate.png)\n\n**Figura 3 - Welcome Page di accesso tramite certificato client**\n\n![Selezione certificato](images/SelectClientCertificate.png)\n\n**Figura 4 - Selezione del certificato client**\n\n![Welcome Page dopo accesso](images/WelcomePageAfterSuccessAuth.png)\n\n**Figura 5 - Welcome Page dopo accesso avvenuto con successo**\n\n\nAccedendo agli _access log_ di Apache è possibile notare due informazioni utili \nal tracciamento delle operazioni eseguite dall'utente:\n\n* Il protocollo SSL\n* Il valore della variabile SSL_CLIENT_S_DN_CN \n\n```log\n172.17.0.1 TLSv1.2 - antonio.musarra@gmail.com [11/Apr/2019:20:17:53 +0000] \"GET /secure/ HTTP/1.1\" 200 4745 \"https://tls-auth.dontesta.it:10443/\" \"Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:66.0) Gecko/20100101 Firefox/66.0\"\n```\n\nIl valore di `SSL_CLIENT_S_DN_CN` è inoltre impostato come **SSLUserName**, questo\nfa in modo che la variabile `REMOTE_USER` sia impostata con il CN del certificato digitale \nche identifica univocamente l'utente. \n\nIn caso di errore in fase di validazione del certificato client, viene mostrata la pagina\ndi errore visibile in Figura 6.\n\n![Pagina di errore in caso di certificato non valido](images/CertificateValidationError.png)\n\n**Figura 6 - Pagina di errore in caso di certificato non valido**\n\n\n## 5 - Build, Run e Push docker image via Makefile\nAl fine di semplificare le operazioni di _build_, _run_ e _push_ dell'immagine docker, \nè stato introdotto il [Makefile](https://github.com/amusarra/docker-apache-ssl-tls-mutual-authentication/blob/develop/Makefile).\n\nPer utilizzare il Makefile occorre che sulla propria macchina siano installati\ncorrettamente i tools di build.\n\nI target disponibili sono i seguenti:\n\n1. **build**: Target di _default_ che esegue il build dell'immagine;\n2. **debug**: Esegue la build dell'immagine e successivamente apre un shell bash sul container; \n3. **run**: Esegue la build dell'immagine e successivamente crea il container lanciando l'applicazione (Apache HTTPD 2.4);\n4. **clean**: Esegue un prune delle immagini;\n5. **remove**: Rimuove l'ultima immagine creata;\n6. **release**: Esegue la build dell'imaggine e successivamente effettua il push su dockerhub.\n\nÉ possibile eseguire il target _release_ solo sul branch master, inoltre, il push \ndell'immagine su DockerHub richiede l'accesso (via username e password) tramite \nil comando `docker login`.\n\n## 6 - Come sono stati generati i certificati\nTutti i certificati di esempio disponibili all'interno del progetto sono stati generati\nutilizzando il tool [OpenSSL](https://openssl.org). Tutti i comandi a seguire sono\nstati e devono eventualmente essere eseguiti dalla root del progetto. I comandi\nhanno l'obiettivo di:\n\n1. Creare la propria Certificate Authority;\n2. Creare la chiave privata del certificato server e **CSR (Certificate Signing Request)**;\n3. Firmare il certificato server da parte della CA (creata in precedenza);\n4. Creare le chiavi private per i certificati client;\n5. Creare le CSR per i certificati client;\n6. Firmare i certificati client da parte della CA;\n7. Esportare la coppia di chiavi in formato PKCS#12.\n\n1 - Creazione della propria Certificate Authority\n```\n$ openssl req -config ./configs/openssl/openssl.cnf -newkey rsa -nodes \\\n\t-keyform PEM -keyout ./configs/certs/blog.dontesta.it.ca.key \\\n\t-x509 -days 3650 -extensions certauth \\\n\t-outform PEM -out ./configs/certs/blog.dontesta.it.ca.cer\n```\n\n2 - Creazione della chiave privata del certificato server e CSR\n```\n$ openssl genrsa -out ./configs/certs/tls-auth.dontesta.it.key 4096\n$ openssl req -config ./configs/openssl/openssl.cnf -new \\\n\t-key ./configs/certs/tls-auth.dontesta.it.key \\\n\t-out ./configs/certs/tls-auth.dontesta.it.req\n```\n\n2 - Firma del certificato server da parte della CA\n```\n$ openssl x509 -req -in ./configs/certs/tls-auth.dontesta.it.req -sha512 \\\n\t-CA ./configs/certs/blog.dontesta.it.ca.cer \\\n\t-CAkey ./configs/certs/blog.dontesta.it.ca.key \\\n\t-set_serial 100 -extfile ./configs/openssl/openssl.cnf \\\n\t-extensions server -days 735 \\\n\t-outform PEM -out ./configs/certs/tls-auth.dontesta.it.cer\n```\nDalla versione 1.2.2 del progetto, i certificati del server sono stati aggiornati\ncon certificati rilasciati da Let's Encrypt (via (ZeroSSL)[https://zerossl.com/])\n\nA seguire i comandi OpenSSL utilizzati per creare i certificati client.\n\n3 - Creazione delle chiavi private\n```\n$ openssl genrsa -out ./configs/certs/tls-client.dontesta.it.key 4096\n$ openssl genrsa -out ./configs/certs/mrossi.dontesta.it.key 4096\n```\n\n4 - Creazione delle CSR\n```\n$ openssl req -config ./configs/openssl/openssl.cnf \\\n\t-new -key ./configs/certs/tls-client.dontesta.it.key \\\n\t-out ./configs/certs/tls-client.dontesta.it.req\n\n$ openssl req -config ./configs/openssl/openssl.cnf \\\n\t-new -key ./configs/certs/mrossi.dontesta.it.key \\\n\t-out ./configs/certs/mrossi.dontesta.it.req\n```\n\n5 - Firma dei certificati client da parte della CA\n```\n$ openssl x509 -req -in ./configs/certs/tls-client.dontesta.it.req -sha512 \\\n\t-CA ./configs/certs/blog.dontesta.it.ca.cer \\\n\t-CAkey ./configs/certs/blog.dontesta.it.ca.key \\\n\t-set_serial 200 -extfile ./configs/openssl/openssl.cnf \\\n\t-extensions client -days 365 \\\n\t-outform PEM -out ./configs/certs/tls-client.dontesta.it.cer\n\n$ openssl x509 -req -in ./configs/certs/mrossi.dontesta.it.req -sha512 \\\n\t-CA ./configs/certs/blog.dontesta.it.ca.cer \\\n\t-CAkey ./configs/certs/blog.dontesta.it.ca.key \\\n\t-set_serial 400 -extfile ./configs/openssl/openssl.cnf \\\n\t-extensions client -days 365 -outform PEM \\\n\t-out ./configs/certs/mrossi.dontesta.it.cer\n```\n\n6 - Esportazione della coppia di chiavi in formato PKCS#12\n```\n$ openssl pkcs12 -export -inkey ./configs/certs/tls-client.dontesta.it.key \\\n\t-in ./configs/certs/tls-client.dontesta.it.cer \\\n\t-out ./configs/certs/tls-client.dontesta.it.p12\n\n$ openssl pkcs12 -export -inkey ./configs/certs/mrossi.dontesta.it.key \\\n\t-in ./configs/certs/mrossi.dontesta.it.cer \\\n\t-out ./configs/certs/mrossi.dontesta.it.p12\n```\n\n## 8 - Come abilitare il protocollo HTTP2\nDalla versione 1.1.0 del progetto, è possibile attivare il protocollo [HTTP/2 (RFC 7540)](https://tools.ietf.org/html/rfc7540).\n\nAttivare il protocollo HTTP/2 (H2 SSL/TLS) è davvero semplice, basta eseguire il\n_run_ dell'immagine impostando le seguenti due varibili con i valori indicati\ndi seguito.\n\n1. APACHE_SSL_VERIFY_CLIENT=require\n2. APACHE_HTTP_PROTOCOLS=h2 http/1.1\n\nIl comando mostrato esegue il run dell'immagine impostando le due variabili\ndi ambiente che consentono l'attivazione del protocollo HTTP/2.\n\n```\ndocker run -i -t -d -p 10443:10443 \\\n\t-e APACHE_SSL_VERIFY_CLIENT='require' \\\n\t-e APACHE_HTTP_PROTOCOLS='h2 http/1.1' \\\n\t--name=apache-ssl-tls-mutual-authentication \\\n\tamusarra/apache-ssl-tls-mutual-authentication:1.1.0\n```\nLa figura a seguire illustra l'utilizzo del protocollo HTTP/2 (H2-TLS) invece del protocollo\nHTTP/1.1 (TLS).\n\n![Abilitazione protocollo HTTP/2 su Apache 2.4](images/Apache2.4_HTTP2_Enabled.png)\n\n**Figura 7 - Abilitazione protocollo HTTP/2 su Apache 2.4**\n\n## 9 - Integrazione del progetto httpbin\nDalla versione 1.2.0 del progetto è stato introdotto [httpbin](https://github.com/postmanlabs/httpbin.git), progetto realizzato da [Kenneth Reitz](http://kennethreitz.org/bitcoin).\n\n[httpbin](https://github.com/postmanlabs/httpbin.git) è un progetto che implementa\nun semplice servizio di richiesta e risposta basato sul protocollo HTTP.\n\nHo deciso d'integrare questo progetto al fine di facilitare i test di accesso tramite\nmutua autenticazione verso servizi REST.\n\nLa variabile d'ambiente `API_BASE_PATH` definisce il _base path_ dei servizi REST\nofferti dal progetto **httpbin** a cui è possibile accedere esclusivamente attraverso una\nmutua autenticazione.\n\nPuntando il proprio browser all'indirizzo [https://tls-auth.dontesta.it:10443/secure/api](https://tls-auth.dontesta.it:10443/secure/api) e dopo aver eseguito l'autenticazione, dovremmo ottenere l'interfaccia di [Swagger](https://swagger.io)\nche mostra la lista dei servizi disponibili e che possiamo richiamare direttamente dal browser. La figura a seguire mostra l'interfaccia di Swagger.\n\n![Visualizzazione Swagger UI](images/httpbin_swagger_ui.png)\n\n**Figura 8 - Visualizzazione Swagger UI e servizi REST esposti da httpbin**\n\nPer ottenere il descrittore dei servizi REST in formato swagger 2.0, è sufficiente\nscaricare il documento json [spec.json](https://tls-auth.dontesta.it:10443/secure/api/spec.json). Il descrittore può essere per esempio importato su [Postman](https://www.getpostman.com/) per poi testare i servizi REST in **muta autenticazione**. \n\n![Esempio di chiamata a servizio REST via Swagger UI](images/httpbin_swagger_ui_call_api.png)\n\n**Figura 9 - Esempio di chiamata a servizio REST via Swagger UI**\n\nPrima di poter eseguire il test con Postman:\n\n1. Il certificato server è di tipo _self-signed_, occorre quindi impostare a __off__ il controllo dei certificati SSL/TLS (vedi figura 10). Questo evita di ottenere l'errore in fase di connessione al servizio;\n2. Importare il certificato client (vedi figura 11). È possibile utilizzare il certificato di esempio **tls-client.dontesta.it.cer** in dotazione con il progetto.\n\n![Disattivazione verifica SSL](images/postman_setting_ssl_1.png)\n\n**Figura 10 - Disattivazione verifica SSL**\n\nPostman richiede il file _cer_ e _key_ al fine di poter aggiungere il certificato\nclient. La password da utilizzare è: **secret**\n\n![Aggiunta del certificato client per la muta autenticazione](images/postmain_add_client_cert.png)\n\n**Figura 11 - Aggiunta del certificato client per la muta autenticazione**\n\nLa figura a seguire mostra un esempio di chiamata al servizio **/secure/api/get**.\nDa notare gli http header `X-Client-Dn` e `X-Client-Verify`, che rispettivamente\nmostrano il DN (Distinguished Name) del certificato client presentato in fase di\nautenticazione e l'esito del processo di autenticazione, in questo caso **SUCCESS**.\n\n![Esempio di chiamata ad uno dei servizi di httpbin](images/postman_rest_call_1.png)\n\n**Figura 12 - Esempio di chiamata ad uno dei servizi di httpbin**\n\n\n## 10 - Conclusioni\nCredo che questo progetto possa essere utile a coloro che hanno la necessità di\nrealizzare un servizio di mutua autenticazione SSL/TLS e non sanno magari\nda dove iniziare. **Questo progetto potrebbe essere quindi un buon punto di partenza.**\n\nOgni suggerimento e/o segnalazione di bug è gradito; consiglio eventualmente di \naprire una [issue](https://github.com/amusarra/docker-apache-ssl-tls-mutual-authentication/issues)\n\n## Project License\nThe MIT License (MIT)\n\nCopyright \u0026copy; 2020 Antonio Musarra's Blog - [https://www.dontesta.it](https://www.dontesta.it \"Antonio Musarra's Blog\"), \n[antonio.musarra@gmail.com](mailto:antonio.musarra@gmail.com \"Antonio Musarra Email\")\n\nPermission is hereby granted, free of charge, to any person obtaining a copy\nof this software and associated documentation files (the \"Software\"), to deal\nin the Software without restriction, including without limitation the rights\nto use, copy, modify, merge, publish, distribute, sublicense, and/or sell\ncopies of the Software, and to permit persons to whom the Software is\nfurnished to do so, subject to the following conditions:\n\nThe above copyright notice and this permission notice shall be included in all\ncopies or substantial portions of the Software.\n\nTHE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\nIMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\nFITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE\nAUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\nLIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,\nOUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE\nSOFTWARE.","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Famusarra%2Fdocker-apache-ssl-tls-mutual-authentication","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Famusarra%2Fdocker-apache-ssl-tls-mutual-authentication","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Famusarra%2Fdocker-apache-ssl-tls-mutual-authentication/lists"}