Το προφίλ μας στο Google Plus
3

openSUSE VPS: Apache, virtual hosts και πιστοποιητικό από Let’s Encrypt

Αναλυτικά και βήμα προς βήμα δείχνουμε πώς εγκαθιστούμε και ρυθμίζουμε τον Apache web server σε ένα VPS με openSUSE, καθώς και πώς αποκτάμε έγκυρα πιστοποιητικά SSL για τα virtual hosts του Apache.

Την όλη διαδικασία έχουμε παρουσιάσει για ένα Raspberry Pi με Raspbian, το οποίο δεν έχουμε στο cloud αλλά στο σπίτι μας. Αυτή τη φορά στρέφουμε την προσοχή μας σε έναν server στο cloud, ο οποίος τρέχει openSUSE Leap 42.2. Αν και η γενική λογική που ακολουθείται είναι παρόμοια με την περίπτωση του Raspbian, οι λεπτομέρειες της υλοποίησης διαφέρουν αρκετά και συνεπώς το παρόν άρθρο κρίνεται απαραίτητο. Πριν ξεκινήσουμε, ας δούμε τη λίστα με τα προαπαιτούμενα.

  • Χρειαζόμαστε ένα VPS στο cloud που τρέχει openSUSE Leap 42.2. Αν είστε στην αναζήτηση για ένα τέτοιο VPS, ίσως αξίζει να δείτε την περίπτωση της γερμανικής Hetzner (βλ., π.χ., εδώ κι εδώ).
  • Στη γραμμή εντολών του VPS έχουμε απομακρυσμένη πρόσβαση μέσω SSH, είτε απευθείας στο λογαριασμό του root είτε σε λογαριασμό άλλου χρήστη που έχει δυνατότητα εκτέλεσης εντολών ως root (π.χ., με τη βοήθεια του sudo).
  • Διαθέτουμε το δικό μας domain name, καθώς και πρόσβαση στον name server που το φιλοξενεί. Σ’ αυτόν, υπάρχει ένα A record που αντιστοιχίζει το domain ή κάποιο subdomain του domain στο (δημόσιο) IP του VPS. Το domain που χρησιμοποιήσαμε για τις ανάγκες της παρουσίασης είναι το colder.xyz και, πιο συγκεκριμένα, στον DNS server υπάρχει ένα A record που αντιστοιχίζει το vatnajokull.colder.xyz στο δημόσιο IP του VPS με το openSUSE. Παρεμπιπτόντως, ιδού ένας τρόπος για να μαθαίνουμε το δημόσιο IP του VPS μας:
    sub0@vatnajokull:~> dig +short myip.opendns.com @resolver1.opendns.com
    
  • Τα ports 80/TCP και 443/TCP του firewall πρέπει να είναι ανοικτά. Μετά την εγκατάσταση του Apache θα καταφύγουμε στο σχετικό module του YaST, ώστε ν’ ανοίξουμε τα προαναφερθέντα ports.
  • Το openSUSE Leap πρέπει να είναι ενημερωμένο:
    sub0@vatnajokull:~> sudo zypper ref
    sub0@vatnajokull:~> sudo zypper lu
    sub0@vatnajokull:~> sudo zypper patch
    
  • Προαιρετικό: Aν ο provider παρέχει τη δυνατότητα για λήψη snapshots, καλό είναι να δημιουργήσουμε ένα πριν πιάσουμε δουλειά. Έτσι, ακόμη κι αν κάνουμε σειρά από λάθη και μπερδευτούμε, ανά πάσα στιγμή θα μπορούμε να γυρίσουμε το VPS σε μια πρότερη καλή κατάσταση.

Εγκατάσταση Apache
Για λόγους ασφαλείας δεν επιτρέπουμε στο VPS μας το SSH login στο λογαριασμό του root. Έχουμε βεβαίως ένα λογαριασμό απλού χρήστη, ο οποίος έχει δυνατότητα για εκτέλεση εντολών διαχειριστή μέσω του εργαλείου sudo. Για ακόμη περισσότερη ευκολία, θα μεταβούμε τώρα στο λογαριασμό του root ώστε να εργαστούμε από εκεί:

sub0@vatnajokull:~> sudo su
vatnajokull:/home/sub0 # cd
vatnajokull:~ #

Η εγκατάσταση του Apache γίνεται με τον αναμενόμενο τρόπο:

vatnajokull:~ # zypper -n in apache2

Η εξαιρετικά απλή διαδικασία της εγκατάστασης του Apache web server κι όλων των εξαρτήσεών του, στο openSUSE Leap.

Η εξαιρετικά απλή διαδικασία της εγκατάστασης του Apache web server κι όλων των εξαρτήσεών του, στο openSUSE Leap.

Αμέσως μετά την εγκατάστασή του, ο Apache είναι ανενεργός (inactive):

vatnajokull:~ # systemctl status apache2.service 
● apache2.service - The Apache Webserver
   Loaded: loaded (/usr/lib/systemd/system/apache2.service; disabled; vendor preset: disabled)
   Active: inactive (dead)

Η ενεργοποίηση γίνεται γράφοντας

vatnajokull:~ # systemctl start apache2.service

Ελέγχοντας ξανά την κατάσταση του Apache, βλέπουμε ότι τώρα είναι πράγματι ενεργός (active) αλλά η υπηρεσία παραμένει απενεργοποιημένη (disabled):

vatnajokull:~ # systemctl status apache2.service 
● apache2.service - The Apache Webserver
   Loaded: loaded (/usr/lib/systemd/system/apache2.service; disabled; vendor preset: disabled)
   Active: active (running) since Sun 2017-01-15 20:41:52 CET; 50s ago
 Main PID: 4057 (httpd-prefork)
   Status: "Total requests: 0; Current requests/sec: 0; Current traffic:   0 B/sec"
    Tasks: 6
[...]
Jan 15 20:41:51 vatnajokull systemd[1]: Starting The Apache Webserver...
Jan 15 20:41:52 vatnajokull systemd[1]: Started The Apache Webserver.

Η ενεργοποίηση της υπηρεσίας γίνεται δίνοντας

vatnajokull:~ # sudo systemctl enable apache2.service
Created symlink from /etc/systemd/system/httpd.service to /usr/lib/systemd/system/apache2.service.
Created symlink from /etc/systemd/system/apache.service to /usr/lib/systemd/system/apache2.service.
Created symlink from /etc/systemd/system/multi-user.target.wants/apache2.service to /usr/lib/systemd/system/apache2.service.

Σημείωση. Αν δεν γνωρίζετε τη διαφορά μεταξύ ενεργοποιημένης κι ενεργής καθώς και τη διαφορά μεταξύ απενεργοποιημένης κι ανενεργής υπηρεσίας, διαβάστε το σχετικό μας άρθρο περί του Systemd.

Πρώτες δοκιμές για τον Apache
Τώρα που ο Apache είναι ενεργός (κι ενεργοποιημένος :)) θα θέλαμε να δούμε αν δουλεύει σωστά, δηλαδή αν σερβίρει κάποια προκαθορισμένη σελίδα Ή Κάτι Τέτοιο (TM). Θα ξεκινήσουμε τους ελέγχους μας πρώτα μέσα από το VPS, με τη βοήθεια ενός browser για την κονσόλα απλού κειμένου και με επίσκεψη στο http://localhost. Μετά θα κάνουμε κι ένα τεστ εξωτερικά, από τον web browser ενός οποιουδήποτε άλλου υπολογιστή και με επίσκεψη στο http://vatnajokull.colder.xyz. Ξεκινάμε από την κονσόλα και με τον browser ονόματι elinks. Αν δεν είναι εγκατεστημένος, το φροντίζουμε αμέσως:

vatnajokull:~ # zypper -n in elinks

Αμέσως μετά επισκεπτόμαστε το http://localhost γράφοντας

vatnajokull:~ # elinks http://localhost

Περιέργως, παίρνουμε το μήνυμα λάθους “Access Forbidden!” (για να εγκαταλείψετε το elinks πατήστε το πλήκτρο [Q] και μετά το [Enter]).

Δεν μπορούμε καν ν' ανοίξουμε τη σελίδα καλωσορίσματος του Apache από το localhost;! Χμ, σαν να μην αρχίζουμε καλά... :/

Δεν μπορούμε καν ν’ ανοίξουμε τη σελίδα καλωσορίσματος του Apache από το localhost;! Χμ, σαν να μην αρχίζουμε καλά… :/

Στο openSUSE, ο κατάλογος στον οποίο βρίσκεται το περιεχόμενο (DocumentRoot) του προκαθορισμένου site (virtual host) του Apache, είναι το /srv/www/htdocs. Πράγματι:

vatnajokull:~ # apachectl -S
VirtualHost configuration:
ServerRoot: "/srv/www"
Main DocumentRoot: "/srv/www/htdocs"
Main ErrorLog: "/var/log/apache2/error_log"
Mutex ssl-stapling-refresh: using_defaults
Mutex ssl-stapling: using_defaults
Mutex ssl-cache: using_defaults
Mutex default: dir="/run/" mechanism=default 
Mutex mpm-accept: using_defaults
PidFile: "/run/httpd.pid"
Define: DUMP_VHOSTS
Define: DUMP_RUN_CFG
User: name="wwwrun" id=30
Group: name="www" id=8

Αν ρίξουμε μια ματιά στον κατάλογο /srv/www/htdocs, θα διαπιστώσουμε ότι είναι κενός:

vatnajokull:~ # ls -lha /srv/www/htdocs
total 8.0K
drwxr-xr-x 2 root root 4.0K Oct  7 17:51 .
drwxr-xr-x 4 root root 4.0K Oct  7 17:51 ..

Για λόγους ασφαλείας ο Apache δεν επιτρέπει το navigation στο DocumentRoot, έτσι παίρνουμε το μήνυμα λάθους που είδαμε πριν λίγο. Ας φτιάξουμε ένα απλό αρχείο HTML μέσα στο DocumentRoot:

vatnajokull:~ # echo '<html><body><h1>This is the default virtual host of Apache@Vatnajokull</h1></body></html>' > /srv/www/htdocs/index.html

Αυτή τη φορά η μετάβαση με το elinks στο http://localhost δεν θα επιστρέψει κάποιο μήνυμα λάθους, αλλά εκείνο που περιλαμβάνεται ανάμεσα στο

<h1>...</h1>

Ο Apache ακούει για αιτήσεις πελατών *και* από το localhost interface, κι αυτό είναι κάτι που το επαληθεύουμε, π.χ., με τη βοήθεια του elinks.

Ο Apache ακούει για αιτήσεις πελατών *και* από το localhost interface, κι αυτό είναι κάτι που το επαληθεύουμε, π.χ., με τη βοήθεια του elinks.

Στη συνέχεια, όμως, επιχειρώντας να επισκεφτούμε το http://vatnajokull.colder.xyz από τον web browser ενός οποιουδήποτε υπολογιστή, διαπιστώνουμε ότι η σύνδεση με τον απομακρυσμένο web server (δηλαδή με τον Apache) δεν προχωρά. Η αποτυχία είναι αναμενόμενη κι οφείλεται στο firewall του openSUSE, το οποίο εξ ορισμού έχει το port 80/TCP κλειστό για το external zone. Φορτώνουμε λοιπόν το module ονόματι “firewall” του YaST (yast2 firewall) και φροντίζουμε ώστε το port 80/TCP να είναι ανοικτό. Και μιας μια κι που αργότερα θα θέλουμε πρόσβαση και στο port 443/TCP, για τις συνδέσεις HTTPS, το ανοίγουμε κι αυτό από τώρα. Δείτε τα screenshots που ακολουθούν, διαβάστε και τις αντίστοιχες περιγραφές.

Το eth0 interface του openSUSE VPS ανήκει στο λεγόμενο external zone. Σε λίγο θα πούμε στο firewall να επιτρέπει τις εισερχόμενες συνδέσεις στο port 80/TCP, για τα interfaces του προαναφερθέντος zone.

Το eth0 interface του openSUSE VPS ανήκει στο λεγόμενο external zone. Σε λίγο θα πούμε στο firewall να επιτρέπει τις εισερχόμενες συνδέσεις στο port 80/TCP, για τα interfaces του προαναφερθέντος zone.

Για το external zone επιτρέπονταν οι εισερχόμενες συνδέσεις προς το port 22/TCP (OpenSSH service), αλλά τώρα φροντίζουμε ώστε να επιτρέπονται και οι εισερχόμενες συνδέσεις προς τα ports 80/TCP και 443/TCP (HTTP και HTTPS αντίστοιχα).

Για το external zone επιτρέπονταν οι εισερχόμενες συνδέσεις προς το port 22/TCP (OpenSSH service), αλλά τώρα φροντίζουμε ώστε να επιτρέπονται και οι εισερχόμενες συνδέσεις προς τα ports 80/TCP και 443/TCP (HTTP και HTTPS αντίστοιχα).

Σύνοψη των αλλαγών που πρόκειται να γίνουν στο σύνολο κανόνων του firewall.

Σύνοψη των αλλαγών που πρόκειται να γίνουν στο σύνολο κανόνων του firewall.

Μετά τις αλλαγές στο firewall, επιχειρώντας να μεταβούμε στο http://vatnajokull.colder.xyz από τον web browser ενός οποιοδήποτε υπολογιστή, βλέπουμε το τυπικό μήνυμα που έχουμε συμπεριλάβει στο index.html. Όλα καλά.

Μετά τις αλλαγές στο firewall του openSUSE μας, από έναν οποιονδήποτε άλλο υπολογιστή βλέπουμε την απλή σελίδα του προκαθορισμένου virtual host που σερβίρει ο Apache.

Μετά τις αλλαγές στο firewall του openSUSE μας, από έναν οποιονδήποτε άλλο υπολογιστή βλέπουμε την απλή σελίδα του προκαθορισμένου virtual host που σερβίρει ο Apache.

Τα virtual hosts του Apache
Ο Apache έχει τη δυνατότητα να διαχειρίζεται περισσότερα από ένα sites, τα οποία βρίσκονται όλα τους στο ίδιο φυσικό ή εικονικό μηχάνημα. Για τον Apache, καθένα απ’ αυτά τα sites είναι ένας διαφορετικός virtual host και περιγράφεται σε κάποιο configuration file, με κατάληξη *.conf. Οι clients του Apache φτάνουν στα sites που σερβίρει πληκτρολογώντας:

  • ένα όνομα, όπως, π.χ., deltahacker.gr, vatnajokull.colder.xyz κ.ο.κ.
  • την κατάλληλη αριθμητική διεύθυνση IP (σπάνια στις μέρες μας)
  • έναν συνδυασμό ονόματος/IP και port (επίσης σπάνια στις μέρες μας).

Στο παρόν άρθρο μάς ενδιαφέρει κυρίως η πλευρά του server, οπότε ας στρέψουμε την προσοχή μας στον Apache. Πληκτρολογώντας, λοιπόν, apachectl -S, παίρνουμε κάποιες πληροφορίες για τον προκαθορισμένο virtual host που υφίσταται αμέσως μετά την εγκατάσταση της υπηρεσίας. Οι παράμετροι που βλέπουμε δεν έχουν σημασία αυτή τη στιγμή. Θα πούμε μόνο ότι το σχετικό αρχείο ρυθμίσεων είναι το default-server.conf, μέσα στον κατάλογο /etc/apache2. Τώρα, η ενδεδειγμένη πρακτική θέλει τα configuration files των virtual hosts να βρίσκονται μέσα στον κατάλογο /etc/apache2/vhosts.d. Ακόμη κι αν έχουμε *μόνο* έναν virtual host, για λόγους καλής διαχείρισης προτείνεται να μη βασιστούμε στο default-server.conf αλλά να δημιουργήσουμε ένα νέο αρχείο *μέσα* στον κατάλογο vhosts.d. Προσέξτε επίσης μια λεπτομέρεια: περισσότερα από ένα virtual hosts είναι δυνατό να περιγράφονται σε *ένα* configuration file. Ξανά όμως για λόγους καλής διαχείρισης, καλό είναι να φροντίζουμε ώστε διαφορετικοί virtual hosts να περιγράφονται σε διαφορετικά configuration files.

Συνοψίζοντας: Κάθε virtual host πρέπει να έχει το δικό του configuration file, το οποίο είναι ένα αρχείο με κατάληξη *.conf και βρίσκεται κάτω από το /etc/apache2/vhosts.d. Όλα, μα όλα, τα αρχεία εντός του συγκεκριμένου καταλόγου που έχουν κατάληξη *.conf, φορτώνονται από τον Apache.

Δημιουργία virtual host για HTTP
Στο openSUSE, μέσα στον κατάλογο /etc/apache2/vhosts.d υπάρχουν τα αρχεία vhost.template και vhost-ssl.template. Όπως φανερώνουν τα ονόματά τους, αποτελούν πρότυπα για τη σύνταξη virtual host configuration files. Είναι φανερό ότι το πρώτο βοηθά στη σύνταξη configuration files για HTTP sites, ενώ το δεύτερο βοηθά στη σύνταξη configuration files για HTTPS sites. Μπορείτε φυσικά να τα αντιγράψετε και να τα μετονομάσετε και να τα τροποποιήσετε καταλλήλως. Για αρχή πάντως, εμείς προτείνουμε κάτι πολύ πιο απλό.

Ξεκινάμε με τη δημιουργία καταλόγων για τη φιλοξενία των αρχείων του site μας, καθώς και των αντίστοιχων αρχείων καταγραφής (log files):

vatnajokull:~ # mkdir -p /srv/www/vatnajokull.colder.xyz/{content,logs}

Κάτω από τον /srv/www φτιάξαμε τον κατάλογο vatnajokull.colder.xyz, ο οποίος σκόπιμα έχει το πλήρες όνομα του site. Εντός αυτού δημιουργήσαμε και τους καταλόγους content και logs: στον πρώτο θα βρίσκονται όλα τα αρχεία του site, ενώ στον δεύτερο τα log files που θα τηρεί ο Apache για το *συγκεκριμένο* site. Ας φτιάξουμε μέσα στον κατάλογο content ένα απλό αρχείο html, ώστε σε λίγο να μπορέσουμε να κάνουμε και τις δοκιμές μας:

vatnajokull:~ # echo '<html><body><h1>Welcome to vatnajokull.colder.xyz!</h1></body></html>' > /srv/www/vatnajokull.colder.xyz/content/index.html

Ωραία. Στο openSUSE μας υπάρχει ένας λογαριασμός απλού χρήστη, με username το sub0. Οι απλοί χρήστες στο openSUSE εξ ορισμού ανήκουν στην ομάδα users. Θέλουμε το περιεχόμενο του vatnajokull.colder.xyz να το διαχειρίζεται ο απλός μας χρήστης, οπότε πριν συνεχίσουμε ας φροντίσουμε για το ιδιοκτησιακό καθεστώς του καταλόγου content κι όλων των περιεχομένων του:

vatnajokull:~ # chown -R sub0:users /srv/www/vatnajokull.colder.xyz/content

Έχει έρθει η στιγμή να συντάξουμε το configuration file για τον virtual host του vatnajokull.colder.xyz. Το σχετικό αρχείο θα το ονομάσουμε vatnajokull.colder.xyz.conf και θα βρίσκεται εντός του καταλόγου /etc/apache2/vhosts.d. Το δημιουργούμε με τον αγαπημένο μας text editor…

vatnajokull:~ # vi /etc/apache2/vhosts.d/vatnajokull.colder.xyz.conf

και φροντίζουμε ώστε να περιλαμβάνει το ακόλουθο περιεχόμενο:

<VirtualHost *:80>
	ServerName vatnajokull.colder.xyz
	ServerAdmin talk2us@colder.xyz
	DocumentRoot /srv/www/vatnajokull.colder.xyz/content
	ErrorLog /srv/www/vatnajokull.colder.xyz/logs/error.log
	CustomLog /srv/www/vatnajokull.colder.xyz/logs/access.log combined
	<Directory "/srv/www/vatnajokull.colder.xyz/content">
		Require all granted
	</Directory>
</VirtualHost>

Νομίζουμε ότι η σημασία των οδηγιών είναι προφανής. Αποθηκεύουμε τις αλλαγές στο vatnajokull.colder.xyz.conf κι επανεκκινούμε τον Apache:

vatnajokull:~ # systemctl restart apache2.service

Αν όλα έχουν πάει καλά, π.χ., δεν υπάρχει κάποιο συντακτικό λάθος στο vatnajokull.colder.xyz.conf, τότε από έναν οποιονδήποτε web browser θα μπορούμε να πηγαίνουμε στο http://vatnajokull.colder.xyz κι εκεί θα βλέπουμε μια λευκή σελίδα με το μήνυμα “Welcome to vatnajokull.colder.xyz!”. Κάθε επίσκεψη θα καταγράφεται στο αρχείο access.log, μέσα στον κατάλογο /srv/www/vatnajokull.colder.xyz/logs.

Το απλό configuration file του virtual host που φτιάξαμε για το vatnajokull.colder.xyz. Πολλά περισσότερα για τη σύνταξη των σχετικών αρχείων μπορείτε να διαβάσετε στο επίσημο documentation του Apache, στο https://httpd.apache.org/docs/2.4/vhosts.

Το απλό configuration file του virtual host που φτιάξαμε για το vatnajokull.colder.xyz. Πολλά περισσότερα για τη σύνταξη των σχετικών αρχείων μπορείτε να διαβάσετε στο επίσημο documentation του Apache, στο https://httpd.apache.org/docs/2.4/vhosts.

Αφού επανεκκινήσουμε τον Apache, ώστε να λάβει υπόψη το νέο virtual host, μια σύντομη δοκιμή από έναν οποιονδήποτε web browser ενός οποιουδήποτε υπολογιστή είναι επιβεβλημένη.

Αφού επανεκκινήσουμε τον Apache, ώστε να λάβει υπόψη το νέο virtual host, μια σύντομη δοκιμή από έναν οποιονδήποτε web browser ενός οποιουδήποτε υπολογιστή είναι επιβεβλημένη.

Λήψη κι εγκατάσταση πιστοποιητικού από Let’s Encrypt
Θα φτιάξουμε σε πολύ λίγο ένα νέο virtual host, για τις συνδέσεις HTTPS. Αν το αντίστοιχο site είναι πειραματικό ή/και προορίζεται μόνο για χρήση εντός του τοπικού δικτύου, τότε χωρίς πρόβλημα μπορούμε να του έχουμε ένα self-signed πιστοποιητικό. Σε περίπτωση όμως που το site θα είναι προσβάσιμο από το Internet, ένα τέτοιο πιστοποιητικό αν μη τι άλλο θα προβληματίζει τους επισκέπτες. Αντί λοιπόν για self-signed πιστοποιητικό, θα εγκαταστήσουμε ένα έγκυρο που θα είναι υπογεγραμμένο από την Αρχή Πιστοποίησης του Let’s Encrypt πρότζεκτ.

Χρειαζόμαστε το certbot, τον επίσημο client του EFF για το Let’s Encrypt. Το certbot ελέγχει αν είμαστε οι κάτοχοι ενός (sub)domain και στη συνέχεια κατεβάζει κι εγκαθιστά ένα υπογεγραμμένο πιστοποιητικό για το ίδιο (sub)domain. Δεν υπάρχει πακέτο RPM με το certbot για το openSUSE, μπορούμε ωστόσο να το πάρουμε απευθείας:

vatnajokull:~ # wget https://dl.eff.org/certbot-auto
--2017-01-24 06:52:38--  https://dl.eff.org/certbot-auto
Resolving dl.eff.org (dl.eff.org)... 173.239.79.196
Connecting to dl.eff.org (dl.eff.org)|173.239.79.196|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 46237 (45K) 
Saving to: ‘certbot-auto’

100%[===================================>] 46,237 280KB/s in 0.2s   

2017-01-24 06:52:42 (280 KB/s) - ‘certbot-auto’ saved [46237/46237]

Πρόκειται για το σκριπτάκι certbot-auto, το οποίο μεταφέρουμε στον κατάλογο ~/bin και φροντίζουμε ώστε να είναι εκτελέσιμο:

vatnajokull:~ # mv certbot-auto bin/
vatnajokull:~ # chmod +x bin/certbot-auto

Αμέσως μετά το τρέχουμε ως ακολούθως:

vatnajokull:~ # ./bin/certbot-auto --apache certonly

Την πρώτη φορά που το certbot-auto τρέχει σ’ ένα σύστημα, ελέγχει για την παρουσία εργαλείων και βιβλιοθηκών που χρειάζεται. Για ό,τι δεν βρίσκει, ζητά άδεια για την εγκατάσταση των αντίστοιχων πακέτων της εκάστοτε διανομής. Εννοείται πως του τη δίνουμε.

Την πρώτη φορά που το certbot-auto τρέχει σ' ένα σύστημα, ελέγχει για την παρουσία εργαλείων και βιβλιοθηκών που χρειάζεται. Για ό,τι δεν βρίσκει, ζητά άδεια για την εγκατάσταση των αντίστοιχων πακέτων για την εκάστοτε διανομή.

Την πρώτη φορά που το certbot-auto τρέχει σ’ ένα σύστημα, ελέγχει για την παρουσία εργαλείων και βιβλιοθηκών που χρειάζεται. Για ό,τι δεν βρίσκει, ζητά άδεια για την εγκατάσταση των αντίστοιχων πακέτων για την εκάστοτε διανομή.

Μετά τη λήψη κι εγκατάσταση όλων των απαραίτητων πακέτων που το certbot-auto χρειάζεται για τη λειτουργία του, το script συνεχίζει με τη λήψη και την εγκατάσταση πιστοποιητικών για τους virtual hosts που βρίσκει στο /etc/apache2/vhosts.d. Προσέξτε τα δύο ακόλουθα screenshots, διαβάστε και τις αντίστοιχες περιγραφές.

Μετά το κατέβασμα και την εγκατάσταση των πακέτων που είναι απαραίτητα για τις λειτουργίες του certbot-auto, το script ζητά ένα έγκυρο email (1). Σ' αυτή τη διεύθυνση θα αποστέλλονται ειδοποιήσεις για πιστοποιητικά που πλησιάζουν στη λήξη τους, καθώς και μηνύματα που αφορούν σε ζητήματα ασφαλείας (δεν έχει τύχει να λάβουμε τέτοιο μήνυμα). Στη συνέχεια καλούμαστε να αποδεχτούμε τους όρους χρήσης της υπηρεσίας του Let's Encrypt (2) και μετά καλούμαστε να υποδείξουμε τα domains για τα οποία θέλουμε πιστοποιητικά (3). Εμείς έχουμε έναν μόνο virtual host, αυτόν για το vatnajokull.colder.xyz, οπότε πατάμε [1] και [Enter].

Μετά το κατέβασμα και την εγκατάσταση των πακέτων που είναι απαραίτητα για τις λειτουργίες του certbot-auto, το script ζητά ένα έγκυρο email (1). Σ’ αυτή τη διεύθυνση θα αποστέλλονται ειδοποιήσεις για πιστοποιητικά που πλησιάζουν στη λήξη τους, καθώς και μηνύματα που αφορούν σε ζητήματα ασφαλείας (δεν έχει τύχει να λάβουμε τέτοιο μήνυμα). Στη συνέχεια καλούμαστε να αποδεχτούμε τους όρους χρήσης της υπηρεσίας του Let’s Encrypt (2) και μετά καλούμαστε να υποδείξουμε τα domains για τα οποία θέλουμε πιστοποιητικά (3). Εμείς έχουμε έναν μόνο virtual host, αυτόν για το vatnajokull.colder.xyz, οπότε πατάμε [1] και [Enter].

Ακολουθούν μια σειρά από ελέγχους και μετά το certbot-auto κατεβάζει τα αρχεία που συγκροτούν το υπογεγραμμένο πιστοποιητικό για το (sub)domain μας. Όλα είναι καλά, έχουμε όμως λίγη δουλειά ακόμα.

Ακολουθούν μια σειρά από ελέγχους και μετά το certbot-auto κατεβάζει τα αρχεία που συγκροτούν το υπογεγραμμένο πιστοποιητικό για το (sub)domain μας. Όλα είναι καλά, έχουμε όμως λίγη δουλειά ακόμα.

Θα παρατηρήσατε ίσως ότι πριν λίγο τρέξαμε το certbot-auto με την παράμετρο –apache και την οδηγία certonly. Η παράμετρος –apache σημαίνει ότι για την ταυτοποίηση και την εγκατάσταση, το certbot-only θα χρησιμοποιήσει το plugin για τον Apache (αυτός είναι ο web server που τρέχουμε). Η δε οδηγία certonly λέει στο script να λάβει ή ν’ ανανεώσει τα πιστοποιητικά, αλλά να μην επιχειρήσει να δημιουργήσει configuration files για τα αντίστοιχα virtual hosts. Κατά τις δοκιμές μας, αρχικά είχαμε παραλείψει την οδηγία certonly και το certbot-auto απέτυχε να δημιουργήσει configuration file για το vatnajokull.colder.xyz. Σκεφτήκαμε λοιπόν να φτιάξουμε μόνοι μας το αντίστοιχο configuration file. Από τη στιγμή άλλωστε που έχουμε έτοιμο το αντίστοιχο αρχείο για τον HTTP host, η δημιουργία νέου αρχείου για τον HTTPS host δεν είναι δύσκολη υπόθεση. Πράγματι, ξεκινάμε αντιγράφοντας και μετονομάζοντας το vatnajokull.colder.xyz.conf, εντός του καταλόγου /etc/apache2/vhosts.d:

vatnajokull:~ # cd /etc/apache2/vhosts.d
vatnajokull:/etc/apache2/vhosts.d # cp vatnajokull.colder.xyz.conf vatnajokull.colder.xyz-tls-le.conf

Τροποποιούμε το αρχείο vatnajokull.colder.xyz-tls-le.conf αλλά και του προσθέτουμε νέο περιεχόμενο, ώστε τελικά να μοιάζει με το ακόλουθο:

<IfModule mod_ssl.c>
<VirtualHost *:443>
        ServerName vatnajokull.colder.xyz
        ServerAdmin talk2us@colder.xyz
        DocumentRoot /srv/www/vatnajokull.colder.xyz/content
        ErrorLog /srv/www/vatnajokull.colder.xyz/logs/error.log
        CustomLog /srv/www/vatnajokull.colder.xyz/logs/access.log combined
        <Directory "/srv/www/vatnajokull.colder.xyz/content">
                Require all granted
        </Directory>
        SSLCertificateFile /etc/letsencrypt/live/vatnajokull.colder.xyz/fullchain.pem
        SSLCertificateKeyFile /etc/letsencrypt/live/vatnajokull.colder.xyz/privkey.pem
        Include /etc/letsencrypt/options-ssl-apache.conf
</VirtualHost>
</IfModule>

Ας κάνουμε μια σύνοψη των αλλαγών/προσθηκών στο νέο configuration file (για τον HTTPS host), σε σύγκριση με το “παλιό” configuration file (για τον HTTP host).

  • Το μπλοκ ανάμεσα στα
    <VirtualHost> ... </VirtualHost>
    

    το οποίο ορίζει έναν virtual host, τώρα είναι εντεταγμένο ανάμεσα στα

    <IfModule mod_ssl.c> ... </IfModule>
    

    Γενικά, ό,τι περιλαμβάνεται ανάμεσα σε μπλοκ της μορφής

    <IfModule [!]module_file|module_identifier> ... </IfModule>
    

    λαμβάνεται υπόψη ανάλογα με το αποτέλεσμα του ελέγχου για την παρουσία ή την απουσία (!) συγκεκριμένου module του Apache. Στο παράδειγμά μας απλά ελέγχουμε αν το module για την υποστήριξη SSL από πλευράς Apache είναι φορτωμένο. Στο openSUSE φορτώνεται εξ ορισμού κι αυτόματα, επομένως ο έλεγχος είναι αληθής κι ο ορισμός του HTTPS host λαμβάνεται υπόψη από τον web server.

  • Ο ορισμός του virtual host για HTTPS ξεκινά με ένα
    <VirtualHost *:443>
    

    κι όχι με ένα

    <VirtualHost *:80>
    

    αφού εξ ορισμού οι συνδέσεις HTTPS γίνονται στο port 443/TCP.

  • Λίγο πριν το τέλος του νέου virtual host έχουν προστεθεί οδηγίες αφενός για το φόρτωμα του cain file (πιστοποιητικό του domain μαζί με το πιστοποιητικό της Αρχής Πιστοποίησης του Let’s Encrypt), αφετέρου για το φόρτωμα του ιδιωτικού κλειδιού που αντιστοιχεί στο πιστοποιητικό (περιλαμβάνει το δημόσιο κλειδί) του domain.
  • Η τελευταία οδηγία πριν το “κλείσιμο” του virtual host συμπεριλαμβάνει όλες τις οδηγίες που παρατίθενται στο αρχείο /etc/letsencrypt/options-ssl-apache.conf (έχει δημιουργήσει το certbot-auto). Ουσιαστικά, οι οδηγίες του συγκεκριμένου αρχείου ενισχύουν την ασφάλεια και την αξιοπιστία των συνδέσεων HTTPS που υποστηρίζει ο Apache μας.

Οι διαφορές στα configuration files των δύο virtual hosts για το vatnajokull.colder.xyz, όπως φαίνονται με τη βοήθεια του εργαλείου diff και με μερικές έξτρα πινελιές :)

Οι διαφορές στα configuration files των δύο virtual hosts για το vatnajokull.colder.xyz, όπως φαίνονται με τη βοήθεια του εργαλείου diff και με μερικές έξτρα πινελιές :)

Όπως ίσως θα παρατηρήσατε, το certbot-auto έχει τακτοποιήσει πιστοποιητικά και ιδιωτικό κλειδί κάτω από το /etc/letsencrypt/live/vatnajokull.colder.xyz. Στην πραγματικότητα, για κάθε domain αποθηκεύει τα σχετικά αρχεία σε έναν κατάλογο της μορφής /etc/letsencrypt/archive/domain. Κάτω από τους καταλόγους της μορφής /etc/letsencrypt/live/domain υπάρχουν symbolic links προς τις πλέον πρόσφατες εκδόσεις πιστοποιητικών και ιδιωτικών κλειδιών για το εκάστοτε domain. Μην ξεχνάτε ότι μετά από συγκεκριμένο χρονικό διάστημα τα πιστοποιητικά λήγουν, οπότε από τη μεριά μας φροντίζουμε να τ’ ανανεώνουμε. Λίγο αργότερα θα δούμε πώς ακριβώς αυτοματοποιούνται οι εν λόγω ανανεώσεις. Προς το παρόν, ας επανεκκινήσουμε τον Apache ώστε να λάβει υπόψη και τον νέο HTTPS host:

vatnajokull:~ # systemctl restart apache2.service

Αν όλα έχουν πάει καλά, από έναν οποιονδήποτε web browser θα είμαστε σε θέση να επισκεφτούμε τη διεύθυνση https://vatnajokull.colder.xyz (προσοχή στο “s”) και θα δούμε το μήνυμα “Welcome to vatnajokull.colder.xyz!”. Όλα καλά — ή για την ακρίβεια *σχεδόν* όλα καλά. Έχουμε λίγη ακόμη δουλειά.

Όπως φαίνεται και με τη βοήθεια του Firefox, ο virtual host για τις συνδέσεις HTTPS προς το vatnajokull.colder.xyz έχει οριστεί σωστά. Υπάρχουν όμως μερικές εκκρεμότητες ακόμα, τις οποίες πρέπει να δούμε.

Όπως φαίνεται και με τη βοήθεια του Firefox, ο virtual host για τις συνδέσεις HTTPS προς το vatnajokull.colder.xyz έχει οριστεί σωστά. Υπάρχουν όμως μερικές εκκρεμότητες ακόμα, τις οποίες πρέπει να δούμε.

Δοκιμές και βελτιώσεις
Μετά την εγκατάσταση πιστοποιητικού για ένα domain, είναι πάντα καλή ιδέα να πηγαίνουμε μια βόλτα από το https://www.ssllabs.com και να κάνουμε μια σειρά από ελέγχους για την ποιότητα των συνδέσεων SSL/TSL που υποστηρίζει ο web server. Το απευθείας URL για την άμεση εκκίνηση των ελέγχων μοιάζει με αυτό:

https://www.ssllabs.com/ssltest/analyze.html?d=vatnajokull.colder.xyz&latest

Οι έλεγχοι διαρκούν λίγα λεπτά κι όταν ολοκληρώνονται βλέπουμε, μεταξύ άλλων, τη συνολική μας αξιολόγηση. Για όσα έχουμε κάνει έως τώρα, αυτή θα είναι “A”. Δείχνει καλή –και είναι καλή– μπορεί όμως να βελτιωθεί και να πάρουμε “A+”.

Αυτό το 'A' δεν είναι άσχημο, αλλά εύκολα μπορούμε να το κάνουμε 'A+'.

Αυτό το “A” δεν είναι άσχημο, αλλά εύκολα μπορούμε να το κάνουμε “A+”.

Όπως είναι ορισμένοι αυτή τη στιγμή οι δύο virtual hosts για το vatnajokull.colder.xyz (ένας για τις συνδέσεις HTTP κι άλλος ένας για τις συνδέσεις HTTPS), όταν επισκεπτόμαστε τη διεύθυνση http://vatnajokull.colder.xyz *δεν* ανακατευθυνόμαστε αυτόματα, όπως θα μπορούσαμε και θα θέλαμε, στο https://vatnajokull.colder.xyz. Μ’ άλλα λόγια, ακόμα κι όταν επιχειρούμε επισφαλή σύνδεση HTTP, αυτομάτως θα πρέπει να γυρνάμε σε ασφαλή σύνδεση ΗTTPS. Aυτό επιτυγχάνεται πολύ εύκολα, προσθέτοντας στο τέλος του configuration file για τον HTTP virtual host μία μόνο γραμμή:

<VirtualHost *:80>
        ServerName vatnajokull.colder.xyz
        ServerAdmin talk2us@colder.xyz
        DocumentRoot /srv/www/vatnajokull.colder.xyz/content
        ErrorLog /srv/www/vatnajokull.colder.xyz/logs/error.log
        CustomLog /srv/www/vatnajokull.colder.xyz/logs/access.log combined
        <Directory "/srv/www/vatnajokull.colder.xyz/content">
                Require all granted
        </Directory>
        Redirect / https://vatnajokull.colder.xyz/
</VirtualHost>

Επανεκκινούμε τον Αpache…

vatnajokull:~ # systemctl restart apache2.service

…κι από έναν οποιονδήποτε web browser μεταβαίνουμε στη διεύθυνση http://vatnajokull.colder.xyz. Παρουσία της οδηγίας Redirect, αυτομάτως ανακατευθυνόμαστε στο https://vatnajokull.colder.xyz (προσοχή, ίσως χρειαστεί ένα refresh για τον browser). Πάρα πολύ ωραία, μόνο που η συγκεκριμένη βελτίωση δεν είναι αρκετή για να μας δώσει το SSLLabs “A+”.

Προκειμένου λοιπόν να κερδίσουμε το “άριστα”, χρειάζεται να δούμε το ζήτημα του HTTP Strict Transport Security (HSTS). Θέτοντας την κατάλληλη τιμή στον HSTS header, διασφαλίζουμε ότι στους επισκέπτες του vatnajokull.colder.xyz *δεν* θα επιτρέπονται απλές συνδέσεις HTTP. Προσέξτε: Αν και αυτή τη στιγμή οι συνδέσεις HTTP προς το vatnajokull.colder.xyz αναβαθμίζονται αυτόματα σε συνδέσεις HTTPS, χωρίς το HSTS header η υλοποίηση επιθέσεων Man-in-The-Middle παραμένει εφικτός κίνδυνος. Για το HSTS, λοιπόν, ανοίγουμε το αρχείο vatnajokull.colder.xyz-tls-le.conf και λίγο πριν το “κλείσιμο” του virtual host προσθέτουμε τρεις νέες γραμμές:

<IfModule mod_ssl.c>
<VirtualHost *:443>
        ServerName vatnajokull.colder.xyz
        ServerAdmin talk2us@colder.xyz
        DocumentRoot /srv/www/vatnajokull.colder.xyz/content
        ErrorLog /srv/www/vatnajokull.colder.xyz/logs/error.log
        CustomLog /srv/www/vatnajokull.colder.xyz/logs/access.log combined
        <Directory "/srv/www/vatnajokull.colder.xyz/content">
                Require all granted
        </Directory>
        SSLCertificateFile /etc/letsencrypt/live/vatnajokull.colder.xyz/fullchain.pem
        SSLCertificateKeyFile /etc/letsencrypt/live/vatnajokull.colder.xyz/privkey.pem
        Include /etc/letsencrypt/options-ssl-apache.conf
        <IfModule mod_headers.c>
                Header always set Strict-Transport-Security "max-age=15552000; includeSubDomains; preload"
        </IfModule>
</VirtualHost>
</IfModule>

Φροντίζουμε αμέσως μετά ώστε το module ονόματι mod_headers να είναι φορτωμένο…

vatnajokull:~ # a2enmod mod_headers

…κι επανεκκινούμε τον Apache ώστε να ληφθούν υπόψη οι αλλαγές για τον ΗTTPS virtual host:

vatnajokull:~ # systemctl status apache2.service

Πηγαίνοντας ξανά στο https://www.ssllabs.com και πραγματοποιώντας τους ελέγχους, με πολλή χαρά διαπιστώσουμε ότι η συνολική μας αξιολόγηση πλέον είναι “A+”.

Αξιολόγηση 'Α+' για τις συνδέσεις TLS/SSL που υποστηρίζει ο Apache μας! Extra bonus: Η υλοποίηση επιθέσεων Man-in-The-Middle προς το site μας καθίσταται εξαιρετικά δύσκολη υπόθεση.

Αξιολόγηση “Α+” για τις συνδέσεις TLS/SSL που υποστηρίζει ο Apache μας! Extra bonus: Η υλοποίηση επιθέσεων Man-in-The-Middle προς το site μας καθίσταται εξαιρετικά δύσκολη υπόθεση.

Αυτόματη ανανέωση
Τα πιστοποιητικά που εκδίδει το Let’s Encrypt διαρκούν για τρεις μήνες. Αν λοιπόν δεν έχουμε φροντίσει για την έγκαιρη ανανέωση του δικού μας, οι επισκέπτες του site θα βλέπουν τη γνωστή, ανησυχητική προειδοποίηση περί ληγμένου πιστοποιητικού. Η ανανέωση των πιστοποιητικών επιτυγχάνεται με τη βοήθεια του certbot-auto. Μπορούμε βεβαίως να φτιάξουμε ένα cronjob για τον root, το οποίο θα φροντίζει γι’ αυτή τη δουλειά αυτόματα. Ξεκινάμε πληκτρολογώντας

vatnajokull:~ # crontab -e

κι αμέσως προσθέτουμε μια νέα εργασία για τον cron daemon. Δείτε το περιεχόμενο του δικού μας crontab:

MAILTO = ""
45 6 * * 7 /root/bin/certbot-auto renew

Κάθε Κυριακή στις 06:45 το πρωί καλείται το certbot-auto με την εντολή renew. Αν και μόνον αν το πιστοποιητικό μας πλησιάζει στη λήξη του, τότε θα ανανεώνεται αυτόματα. Παρατηρήστε ότι έχουμε πει στον cron daemon να μη στέλνει email κάθε φορά που εκτελείται κάποιο cronjob για τον root. Σε περίπτωση που παρατηρήσουμε ότι κάτι δεν έχει πάει καλά με την ανανέωση θα ανοίξουμε το αρχείο καταγραφής letsencrypt.log, μέσα στον κατάλογο /var/log/letsencrypt. Και μια τελευταία σημείωση: Καλό είναι να βάλετε διαφορετική μέρα και ώρα στο cronjob σας, ώστε να μην πέφτουμε όλοι μαζί πάνω στους servers του Let’s Encrypt.

3 Responses to “openSUSE VPS: Apache, virtual hosts και πιστοποιητικό από Let’s Encrypt”

  1. fr33k3r | 09/02/2017 at 08:16

    Πάρα πολύ καλό το άρθρο παιδιά. Επειδή δεν έχω παίξει ακόμη με vps έχετε γράψει αρκετά και θα ήθελα να ασχοληθώ…ποια λύση προτείνετε σαν φθηνότερη ή με free κάποιο διάστημα όσο πειραματίζομαι?

    • subZraw | 09/02/2017 at 09:05

      Καλημέρα,
      Για τον φθηνότερο provider δεν μπορούμε να σε βοηθήσουμε, δεν έχουμε κάνει σχετική έρευνα δηλαδή. Πάντως η Hetzner είναι πράγματι πιο φθηνή από τον άλλο αγαπημένο μας provider, που είναι η Digital Ocean.

      • fr33k3r | 09/02/2017 at 09:26

        Αυτό βλέπω και έκανα και ένα account αρχή ….thnx… :)

Leave a Reply

You must be logged in to post a comment.

Σύνδεση

Αρχείο δημοσιεύσεων