Teampass è un gestore password web based utile per memorizzare e accedere alle password in modo sicuro utilizzando il database MySQL.
È stato progettato per l’ambiente aziendale e fornisce un potente strumento per personalizzare l’accesso delle password a seconda del ruolo degli utenti.
Questo articolo spiega come installare e configurare Teampass su Ubuntu 16.04 con Apache e Mysql.
PRE REQUISITI
Apache, MySQL, PHP 5.5.0 o superiore
Estensioni PHP: mcrypt, openssl, ldap (if used), mbstring, bcmath, iconv, xml, gd, openssl, mysqlnd
Unzip
INSTALLAZIONE UNZIP
Installare il pacchetto unzip con il comando
0 |
sudo apt-get install unzip |
INSTALLAZIONE APACHE E MYSQL SERVER
Apache2 è disponibile come pacchetto in Ubuntu, installarlo utilizzando il seguente comando.
La directory principale del virtual host predefinito di Apache è /var/www/html e il file di configurazione principale è /etc/apache2/apache2.conf
Lanciamo il comando:
0 |
sudo apt-get install apache2 |
Installiamo anche il MySQL Server con il comando:
0 |
sudo apt-get install mysql-server |
Inserire la password dell’utente di root di MySQL
Reinserire la password di root quindi OK
Facoltativamente, è possibile procedere con l’installazione sicura di MySql.
Basta rispondere a poche domande per un’installazione sicura.
Lanciamo il comando:
0 |
sudo mysql_secure_installation |
Quindi rispondiamo alle domande come segue:
0 1 2 3 4 5 |
VALIDATE PASSWORD PLUGIN can be used to test passwords and improve security. It checks the strength of password and allows the users to set only those passwords which are secure enough. Would you like to setup VALIDATE PASSWORD plugin? Press y|Y for Yes, any other key for No: <strong>Y</strong> |
0 1 2 3 4 5 6 |
There are three levels of password validation policy: LOW Length >= 8 MEDIUM Length >= 8, numeric, mixed case, and special characters STRONG Length >= 8, numeric, mixed case, special characters and dictionary file Please enter 0 = LOW, 1 = MEDIUM and 2 = STRONG: 1 |
0 1 2 3 4 5 6 7 8 9 10 |
Estimated strength of the password: 100 Change the password for root ? ((Press y|Y for Yes, any other key for No) : <strong>N</strong> ... skipping. By default, a MySQL installation has an anonymous user, allowing anyone to log into MySQL without having to have a user account created for them. This is intended only for testing, and to make the installation go a bit smoother. You should remove them before moving into a production environment. |
0 1 2 |
Remove anonymous users? (Press y|Y for Yes, any other key for No) : Y Success. |
0 1 2 3 4 5 6 7 8 9 10 |
Normally, root should only be allowed to connect from 'localhost'. This ensures that someone cannot guess at the root password from the network. Disallow root login remotely? (Press y|Y for Yes, any other key for No) : Y By default, MySQL comes with a database named 'test' that anyone can access. This is also intended only for testing, and should be removed before moving into a production environment. |
0 1 2 3 4 5 6 7 8 9 |
Remove test database and access to it? (Press y|Y for Yes, any other key for No) : Y - Dropping test database... Success. - Removing privileges on test database... Success. Reloading the privilege tables will ensure that all changes made so far will take effect immediately. |
0 1 2 3 4 |
Reload privilege tables now? (Press y|Y for Yes, any other key for No) : Y Success. All done! |
INSTALLAZIONE PHP
Installiamo il PHP 7 ed i moduli di Apache
0 |
sudo apt-get install php libapache2-mod-php |
Ora installare tutte le estensioni php richieste da teampass con il comando
0 |
sudo apt-get install php-mcrypt php-curl php-mysql php-opcache php-mbstring php-ldap php-bcmath php-gd php-xml php-common php-mysqlnd |
Verifichiamo la versione PHP con il comando
0 |
php -v |
Dovremmo leggere le seguenti righe
0 1 2 3 |
PHP 7.0.22-0ubuntu0.16.04.1 (cli) ( NTS ) Copyright (c) 1997-2017 The PHP Group Zend Engine v3.0.0, Copyright (c) 1998-2017 Zend Technologies with Zend OPcache v7.0.22-0ubuntu0.16.04.1, Copyright (c) 1999-2017, by Zend Technologies |
CREAZIONE DATABASE IN MYSQL
Procedere alla creazione del database con relativa utenza per Teampass
0 |
mysql -u root -p |
Creaimo il database con il comando:
0 |
create database teampass; |
Se è tutto OK dovremmo leggere le seguenti righe:
Query OK, 1 row affected (0,00 sec)
Creaimo l’utenza con relativa password:
0 |
grant all privileges on teampass.* to teampassuser@localhost identified by 'PASSWORD-USER'; |
Al posto di PASSWORD-USER inserire la password desiderata
Se è tutto OK dovremmo leggere la seguente riga:
Query OK, 0 rows affected, 1 warning (0,00 sec)
Lanciamo quindi il comando:
0 |
flush privileges; |
Se è tutto OK dovremmo leggere la seguente riga:
Query OK, 0 rows affected (0,00 sec)
Usciamo dalla configurazione di MySQL con il comando:
0 |
quit |
CONFIGURAZIONE DI APACHE PER TEAMPASS
Procediamo al download teampass da github e alla scompattazione nella root folder del webiste in /var/www/html
Posizioniamoci nella cartella /var/www/html con il comando:
0 |
cd /var/www/html |
Scarichiamo Teampass con il comando:
0 |
sudo wget -q https://github.com/nilsteampassnet/TeamPass/archive/master.zip |
Scompattiamo il file zippato con il comando:
0 |
sudo unzip master.zip |
Spostiamo la cartella TeamPass-master in teampass con il comando:
0 |
sudo mv TeamPass-master/ teampass |
Quindi cambiamo i permessi con il comando:
0 |
sudo chown -R www-data:www-data teampass/ |
Modificare il tempo massimo di esecuzione di PHP portandolo a 120 con il comando:
0 |
sudo nano /etc/php/7.0/apache2/php.ini |
Di default il valore dovrebbe essere max_execution_time = 30
Impostiamo quindi la con riga max_execution_time = 120
Riavviamo Apache per applicare le modifiche con il comando:
0 |
sudo service apache2 restart |
Creare la Cartella Teampass Key all’interno del path /var/www/html/teampass quindi modificare i permessi e l’owner.
Eseguiamo i tre comandi elencati di seguito:
0 1 2 |
sudo mkdir -p /var/www/html/teampass/keys sudo chmod 755 /var/www/html/teampass/keys sudo chown -R www-data:www-data /var/www/html/teampass/keys |
Adesso lanciamo i seguenti comandi per poter installare il software senza problemi:
0 1 2 3 4 5 6 7 8 9 10 |
sudo chmod 755 /var/www/html/teampass/install sudo chown -R www-data:www-data /var/www/html/teampass/install sudo chmod 755 /var/www/html/teampass/includes sudo chown -R www-data:www-data /var/www/html/teampass/includes sudo chmod 755 /var/www/html/teampass/files sudo chown -R www-data:www-data /var/www/html/teampass/files sudo chmod 755 /var/www/html/teampass/upload sudo chown -R www-data:www-data /var/www/html/teampass/upload |
INSTALLAZIONE TEAMPASS
Richiamare da un quaisasi browser il link http://IP_SERVER/teampass
Cliccare Next
Lasciare tutto inviariato quindi cliccare Launch
Se non c’è nessun problema dovremmo vedere una schermata come quella sovrastante senza nessun errore.
In caso di errori correggerli e cliccare su Restart per ripetere i controlli lato Server.
Cliccare su Next per procedere con l’installazione
Inserire tutti i dati per la connessione dal database MySQL
Cliccare Launch
Se è tutto OK dovremmo vedere una schermata come quella sovrastante
Quindi clicchiamo su Next per procedere con l’installazione
Settare il path per la Saltkey (abbiamo creato la cartella in precedenza) quindi inserire una passowrd per l’Administrator
Cliccare su Launch
Se è tutto corretto dovremmo vedere una schermata come quella sovrastante.
Clicchiamo su Next per procedere
Cliccare su Launch per iniziare a popoplare il database
Cliccare su Next per continuare l’installazione
Cliccare su Launch per scrivere tutti i settaggi nei files di configurazione
Se è tutto ok dovremmo vedere una schermata come quella sovrastante
Cliccare su Next per procedere
Cliccare su Move to Home Page
ATTENZIONE: Prima di accedere alla pagina web di Teampass collegarsi al server in SSH e verificare se la cartella INSTALL è presente.
Se presente lanciare il seguente comando per cancellare la cartella di installazione:
0 |
sudo rmdir install/ |
Richiamando il link Http://IP_DEL_SERVER/teampass
Accedere con l’utenza admin e la password settata in precedenza quindi procedere alla configurazione del software.
CONFIGURARE TEAMPASS IN HTTPS
Per la generazione del certifcato lanciare il seguente comando:
0 |
sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/ssl/private/apache-selfsigned.key -out /etc/ssl/certs/apache-selfsigned.crt |
NOTA BENE:
openssl: Questo è lo strumento da riga di comando di base per la creazione e la gestione di certificati OpenSSL, chiavi e altri file.
req: Questo sottocomando specifica che vogliamo utilizzare la gestione della richiesta di firma di certificati X.509 (CSR). Il “X.509” è uno standard di infrastruttura chiave pubblica che SSL e TLS aderiscono per la gestione delle chiavi e del certificato. Vogliamo creare un nuovo X.509 cert, quindi stiamo usando questo sottocomando.
-x509: questo modifica ulteriormente il precedente sottocomando dicendo all’utility che vogliamo creare un certificato auto-firmato anziché generare una richiesta di firma del certificato, come accade normalmente.
-nodi: questo indica a OpenSSL di ignorare l’opzione per proteggere il nostro certificato con una passphrase. Abbiamo però bisogno di Apache per poter leggere il file, senza intervento dell’utente, quando il server viene avviato. Una passphrase impedirebbe che questo accada perché dovremmo entrare dopo ogni riavvio.
-days 365: Questa opzione imposta la durata del tempo in cui il certificato sarà considerato valido.
-newkey rsa: 2048: specifica che vogliamo generare un nuovo certificato e una nuova chiave contemporaneamente. Non abbiamo creato la chiave necessaria per firmare il certificato in un passaggio precedente, quindi abbiamo bisogno di crearlo insieme al certificato. La parte di rsa: 2048 gli dice di fare un tasto RSA che sia lungo 2048 bit.
-keyout: questa riga dice a OpenSSL dove posizionare il file di chiave privata generato che stiamo creando.
-out: Questo indica a OpenSSL dove inserire il certificato che stiamo creando.
Rispondere alle domande come riportato di seguito:
0 1 2 3 4 5 6 |
Country Name (2 letter code) [AU]:IT State or Province Name (full name) [Some-State]:ITALY Locality Name (eg, city) []:TURIN Organization Name (eg, company) [Internet Widgits Pty Ltd]:COMPANY Organizational Unit Name (eg, section) []:IT Common Name (e.g. server FQDN or YOUR name) []:NOME_DNS_SERVER Email Address []:mail@mailserver.it |
Generare il certificato con il comando ed attendere qualche minuto:
0 |
sudo openssl dhparam -out /etc/ssl/certs/dhparam.pem 2048 |
CONFIGURARE APACHE PER L’UTILIZZO DI SSL
Per permettere ad Apache di utilizzare l’SSL creare il seguente file:
0 |
sudo nano /etc/apache2/conf-available/ssl-params.conf |
Inseriamo nel file di configurazione le seguenti righe:
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
# from https://cipherli.st/ # and https://raymii.org/s/tutorials/Strong_SSL_Security_On_Apache2.html SSLCipherSuite EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH SSLProtocol All -SSLv2 -SSLv3 SSLHonorCipherOrder On # Disable preloading HSTS for now. You can use the commented out header line that includes # the "preload" directive if you understand the implications. #Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains; preload" Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains" Header always set X-Frame-Options DENY Header always set X-Content-Type-Options nosniff # Requires Apache >= 2.4 SSLCompression off SSLSessionTickets Off SSLUseStapling on SSLStaplingCache "shmcb:logs/stapling-cache(150000)" SSLOpenSSLConfCmd DHParameters "/etc/ssl/certs/dhparam.pem" |
Salviamo e chiudiamo il file ssl-params.conf
MODIFICA DEL FILE SSL VIRTUAL HOST SU APACHE
Per sicurezza facciamo una copia del file default-ssl.conf con il comando
0 |
sudo cp /etc/apache2/sites-available/default-ssl.conf /etc/apache2/sites-available/default-ssl.conf.bak |
Aprire il file di configurazione con il comando:
0 |
sudo nano /etc/apache2/sites-available/default-ssl.conf |
Di seguito il contenuto del file originale.
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 |
<IfModule mod_ssl.c> <VirtualHost _default_:443> ServerAdmin webmaster@localhost DocumentRoot /var/www/html # Available loglevels: trace8, ..., trace1, debug, info, notice, warn, # error, crit, alert, emerg. # It is also possible to configure the loglevel for particular # modules, e.g. #LogLevel info ssl:warn ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined # For most configuration files from conf-available/, which are # enabled or disabled at a global level, it is possible to # include a line for only one particular virtual host. For example the # following line enables the CGI configuration for this host only # after it has been globally disabled with "a2disconf". #Include conf-available/serve-cgi-bin.conf # SSL Engine Switch: # Enable/Disable SSL for this virtual host. SSLEngine on # A self-signed (snakeoil) certificate can be created by installing # the ssl-cert package. See # /usr/share/doc/apache2/README.Debian.gz for more info. # If both key and certificate are stored in the same file, only the # SSLCertificateFile directive is needed. SSLCertificateFile /etc/ssl/certs/ssl-cert-snakeoil.pem SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key # Server Certificate Chain: # Point SSLCertificateChainFile at a file containing the # concatenation of PEM encoded CA certificates which form the # certificate chain for the server certificate. Alternatively # the referenced file can be the same as SSLCertificateFile # when the CA certificates are directly appended to the server # certificate for convinience. #SSLCertificateChainFile /etc/apache2/ssl.crt/server-ca.crt # Certificate Authority (CA): # Set the CA certificate verification path where to find CA # certificates for client authentication or alternatively one # huge file containing all of them (file must be PEM encoded) # Note: Inside SSLCACertificatePath you need hash symlinks # to point to the certificate files. Use the provided # Makefile to update the hash symlinks after changes. #SSLCACertificatePath /etc/ssl/certs/ #SSLCACertificateFile /etc/apache2/ssl.crt/ca-bundle.crt # Certificate Revocation Lists (CRL): # Set the CA revocation path where to find CA CRLs for client # authentication or alternatively one huge file containing all # of them (file must be PEM encoded) # Note: Inside SSLCARevocationPath you need hash symlinks # to point to the certificate files. Use the provided # Makefile to update the hash symlinks after changes. #SSLCARevocationPath /etc/apache2/ssl.crl/ #SSLCARevocationFile /etc/apache2/ssl.crl/ca-bundle.crl # Client Authentication (Type): # Server Certificate Chain: # Point SSLCertificateChainFile at a file containing the # concatenation of PEM encoded CA certificates which form the # certificate chain for the server certificate. Alternatively # the referenced file can be the same as SSLCertificateFile # when the CA certificates are directly appended to the server # certificate for convinience. #SSLCertificateChainFile /etc/apache2/ssl.crt/server-ca.crt # Certificate Authority (CA): # Set the CA certificate verification path where to find CA # certificates for client authentication or alternatively one # huge file containing all of them (file must be PEM encoded) # Note: Inside SSLCACertificatePath you need hash symlinks # to point to the certificate files. Use the provided # Makefile to update the hash symlinks after changes. #SSLCACertificatePath /etc/ssl/certs/ #SSLCACertificateFile /etc/apache2/ssl.crt/ca-bundle.crt # Certificate Revocation Lists (CRL): # Set the CA revocation path where to find CA CRLs for client # authentication or alternatively one huge file containing all # of them (file must be PEM encoded) # Note: Inside SSLCARevocationPath you need hash symlinks # to point to the certificate files. Use the provided # Makefile to update the hash symlinks after changes. #SSLCARevocationPath /etc/apache2/ssl.crl/ #SSLCARevocationFile /etc/apache2/ssl.crl/ca-bundle.crl # Client Authentication (Type): # Client certificate verification type and depth. Types are # none, optional, require and optional_no_ca. Depth is a # number which specifies how deeply to verify the certificate # issuer chain before deciding the certificate is not valid. #SSLVerifyClient require #SSLVerifyDepth 10 # SSL Engine Options: # Set various options for the SSL engine. # o FakeBasicAuth: # Translate the client X.509 into a Basic Authorisation. This means that # the standard Auth/DBMAuth methods can be used for access control. The # user name is the `one line' version of the client's X.509 certificate. # Note that no password is obtained from the user. Every entry in the user # file needs this password: `xxj31ZMTZzkVA'. # o ExportCertData: # This exports two additional environment variables: SSL_CLIENT_CERT and # SSL_SERVER_CERT. These contain the PEM-encoded certificates of the # server (always existing) and the client (only existing when client # authentication is used). This can be used to import the certificates # into CGI scripts. # o StdEnvVars: # This exports the standard SSL/TLS related `SSL_*' environment variables. # Per default this exportation is switched off for performance reasons, # because the extraction step is an expensive operation and is usually # useless for serving static content. So one usually enables the # exportation for CGI and SSI requests only. # o OptRenegotiate: # This enables optimized SSL connection renegotiation handling when SSL # directives are used in per-directory context. #SSLOptions +FakeBasicAuth +ExportCertData +StrictRequire <FilesMatch "\.(cgi|shtml|phtml|php)$"> SSLOptions +StdEnvVars # number which specifies how deeply to verify the certificate # issuer chain before deciding the certificate is not valid. #SSLVerifyClient require #SSLVerifyDepth 10 # SSL Engine Options: # Set various options for the SSL engine. # o FakeBasicAuth: # Translate the client X.509 into a Basic Authorisation. This means that # the standard Auth/DBMAuth methods can be used for access control. The # user name is the `one line' version of the client's X.509 certificate. # Note that no password is obtained from the user. Every entry in the user # file needs this password: `xxj31ZMTZzkVA'. # o ExportCertData: # This exports two additional environment variables: SSL_CLIENT_CERT and # SSL_SERVER_CERT. These contain the PEM-encoded certificates of the # server (always existing) and the client (only existing when client # authentication is used). This can be used to import the certificates # into CGI scripts. # o StdEnvVars: # This exports the standard SSL/TLS related `SSL_*' environment variables. # Per default this exportation is switched off for performance reasons, # because the extraction step is an expensive operation and is usually # useless for serving static content. So one usually enables the # exportation for CGI and SSI requests only. # o OptRenegotiate: # This enables optimized SSL connection renegotiation handling when SSL # directives are used in per-directory context. #SSLOptions +FakeBasicAuth +ExportCertData +StrictRequire <FilesMatch "\.(cgi|shtml|phtml|php)$"> SSLOptions +StdEnvVars </FilesMatch> <Directory /usr/lib/cgi-bin> SSLOptions +StdEnvVars </Directory> # SSL Protocol Adjustments: # The safe and default but still SSL/TLS standard compliant shutdown # approach is that mod_ssl sends the close notify alert but doesn't wait for # the close notify alert from client. When you need a different shutdown # approach you can use one of the following variables: # o ssl-unclean-shutdown: # This forces an unclean shutdown when the connection is closed, i.e. no # SSL close notify alert is send or allowed to received. This violates # the SSL/TLS standard but is needed for some brain-dead browsers. Use # this when you receive I/O errors because of the standard approach where # mod_ssl sends the close notify alert. # o ssl-accurate-shutdown: # This forces an accurate shutdown when the connection is closed, i.e. a # SSL close notify alert is send and mod_ssl waits for the close notify # alert of the client. This is 100% SSL/TLS standard compliant, but in # practice often causes hanging connections with brain-dead browsers. Use # this only for browsers where you know that their SSL implementation # works correctly. # Notice: Most problems of broken clients are also related to the HTTP # keep-alive facility, so you usually additionally want to disable # keep-alive for those clients, too. Use variable "nokeepalive" for this. # Similarly, one has to force some clients to use HTTP/1.0 to workaround # their broken HTTP/1.1 implementation. Use variables "downgrade-1.0" and # "force-response-1.0" for this. # BrowserMatch "MSIE [2-6]" \ # nokeepalive ssl-unclean-shutdown \ # downgrade-1.0 force-response-1.0 SSLOptions +StdEnvVars </Directory> # SSL Protocol Adjustments: # The safe and default but still SSL/TLS standard compliant shutdown # approach is that mod_ssl sends the close notify alert but doesn't wait for # the close notify alert from client. When you need a different shutdown # approach you can use one of the following variables: # o ssl-unclean-shutdown: # This forces an unclean shutdown when the connection is closed, i.e. no # SSL close notify alert is send or allowed to received. This violates # the SSL/TLS standard but is needed for some brain-dead browsers. Use # this when you receive I/O errors because of the standard approach where # mod_ssl sends the close notify alert. # o ssl-accurate-shutdown: # This forces an accurate shutdown when the connection is closed, i.e. a # SSL close notify alert is send and mod_ssl waits for the close notify # alert of the client. This is 100% SSL/TLS standard compliant, but in # practice often causes hanging connections with brain-dead browsers. Use # this only for browsers where you know that their SSL implementation # works correctly. # Notice: Most problems of broken clients are also related to the HTTP # keep-alive facility, so you usually additionally want to disable # keep-alive for those clients, too. Use variable "nokeepalive" for this. # Similarly, one has to force some clients to use HTTP/1.0 to workaround # their broken HTTP/1.1 implementation. Use variables "downgrade-1.0" and # "force-response-1.0" for this. # BrowserMatch "MSIE [2-6]" \ # nokeepalive ssl-unclean-shutdown \ # downgrade-1.0 force-response-1.0 </VirtualHost> </IfModule> |
Le righe da modificare sono le seguenti:
<IfModule mod_ssl.c>
<VirtualHost _default_:443>
ServerAdmin [email protected]
ServerName nome_del_server_o_indirizzo_IP
DocumentRoot /var/www/html
# Available loglevels: trace8, …, trace1, debug, info, notice, warn,
# error, crit, alert, emerg.
# It is also possible to configure the loglevel for particular
# modules, e.g.
#LogLevel info ssl:warn
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
# For most configuration files from conf-available/, which are
# enabled or disabled at a global level, it is possible to
# include a line for only one particular virtual host. For example the
# following line enables the CGI configuration for this host only
# after it has been globally disabled with “a2disconf”.
#Include conf-available/serve-cgi-bin.conf
# SSL Engine Switch:
# Enable/Disable SSL for this virtual host.
SSLEngine on
# A self-signed (snakeoil) certificate can be created by installing
# the ssl-cert package. See
# /usr/share/doc/apache2/README.Debian.gz for more info.
# If both key and certificate are stored in the same file, only the
# SSLCertificateFile directive is needed.
SSLCertificateFile /etc/ssl/certs/apache-selfsigned.crt
SSLCertificateKeyFile /etc/ssl/private/apache-selfsigned.key
Quindi decommentare le seguenti righe (sono al fondo del file di configurazione):
BrowserMatch “MSIE [2-6]” \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0
Salvare il file e chiuderlo
Apriamo il file di configurazione 000-default.conf per impostare il redirect in HTTPS
0 |
sudo nano /etc/apache2/sites-available/000-default.conf |
Inserire all’interno del VirtualHost la riga sul redirect
0 |
Redirect "/" "https://NOME_SERVER_O_IP_ADDRESS/" |
Dovremmo vedere una schermata come quella sovrastante
Salvare e chiudere il file di configurazione
ABILITARE LE MODIFICHE IN APACHE
Lanciamo i seguenti comandi in sequenza:
0 1 2 3 4 5 6 7 8 |
sudo a2enmod ssl sudo a2enmod headers sudo a2ensite default-ssl sudo a2enconf ssl-params sudo apache2ctl configtest |
Riavviamo Apache per applicare le modifiche
0 |
sudo systemctl restart apache2 |
Adesso se proviamo a richiamare il nostro teampass con il link
https://IP_SERVER/teampass
Dovrebbe risponderci il teampass
A questo punto possiamo impostare il Redirect permanente e quindi consentendo solo il traffico crittografato.
Per fare questo dobbiamo modificare nuovamente l’host virtuale apache non crittografato per rendere permanente il reindirizzamento.
Apriamo il file sudo nano 000-default.conf con il comando
0 |
sudo nano /etc/apache2/sites-available/000-default.conf |
Modifichiamo la riga creata in precedenza aggiungendo “permanent”
Redirect permanent “/” “https://NOME_SERVER_O_IP_ADDRESS/”
Se è tutto corretto dovremmo vedere una schermata come quella sovrastante
Salvare e chiudere il file
Testiamo quindi la configurazione di Apache con il comando:
0 |
sudo apache2ctl configtest |
Se è tutto ok dovremmo ricevere il messaggio Syntax OK
Riavviamo Apache per applicare le modifiche:
0 |
sudo systemctl restart apache2 |
Adesso se proviamo a richiamare il sito in http vedremo che andarà in automatico in https.
Sono Raffaele Chiatto, un appassionato di informatica a 360°…
Mi sono avvicinato al mondo dell’informatica nel lontano 1996 con Windows 95 e da allora non ho più smesso di dedicarmi allo studio ed approfondimento di questo settore.
Laureato in Ingegneria Informatica nel 2009, lavoro nel campo dell’IT dal lontano 2001.
0 commenti