Linux-palvelimet – Harjoitus 4

Osallistun Haaga-Helia ammattikorkeakoulussa Linux-palvelimet kurssille, jonka opettajana toimii Tero Karvinen. Kaikki tehtävät ovat hänen verkkosivuiltaan http://terokarvinen.com/.

Suoritan tehtävän pöytätietokoneellani, jossa pyörii Debian 9.7. ja samalla käytän Digital Oceanilta vuokrattua virtuaalipalvelinta, jossa pyörii Ubuntu 18.04.

Tehtävänanto kuuluu seuraavasti:

a) Laita hankkimallesi virtuaalipalvelimelle mahdollisuus tehdä kotisivuja normaalin käyttäjän oikeuksin.
s) Laita hankkimallesi virtuaalipalvelimelle käyttäjän kotihakemistoon tallennettu sivu näkymään Apachen oletussivuna.
y) Etsi palvelimesi lokeista esimerkkejä murtautumisyrityksistä. Voit etsiä lisätietoa IP-osoitteista ottamatta niihin yhteyttä esimerkiksi komennoilla ipcalc, geoiplookup ja whois.
b) Tee weppisivuja paikallisella koneellasi ja kopioi ne palvelimelle scp-komennolla.
c) Laita palvelimellesi jokin yksinkertainen PHP-sivu. Voit esimerkiksi tulostaa käyttäjän IP-osoitteen$_SERVER[‘REMOTE_ADDR’] tms. Ole huolellinen, jos otat vastaan syötteitä lomakkeilla (forms).

Vapaaehtoisia tehtäviä
Vinkkejä: lue linkitetyt artikkelit aikataulusta yltä ennenkuin alat tehdä tehtäviä. Muista viitata kaikkiin lähteisiin. Käytä aina hyviä salasanoja, joka hetki ja joka paikassa.
r) Kokeile julkista virtuaalipalvelinta (VPS). Voit vuokrata palvelimen esimerkiksi Linodelta, Amazonilta, DigitalOceanilta, OVH:lta tai monista muista paikoista. Edullisinta on käyttää GitHub Education -paketista DigitalOceanin palveluita.
Vaihtoehto: jos et jostain syystä halua vuokrata virtuaalipalvelinta, voit kokeilla tehdä testipalvelimen vagrantilla, mutta tämä ei ole yhtä jännittävää.
x) Laita julkinen domain-nimi osoittamaan koneeseesi. NameCheap ja Gandi ovat tunnettuja nimien vuokraajia. GitHub Education -paketista saa NameCheapilta .me domainin ilmaiseksi vuodeksi.

v) Laita monta DNS-nimeä samaan IP-osoitteeseen. Apache Name Based Virtual Hosting.t) Asenna WordPress. Se on maailman suosituin sisällönhallintajärjestelmä (CMS). Samalla opit asentamaan kolmannen osapuolen valmiita PHP-ohjelmia. WordPress kannattaa asentaa wordpress.org:sta löytyvästä tervapallosta (.tar.gz).
u) Kokeile WordPressia kirjoittamalla esimerkkisisältöä.
WordPress vapaaehtoisia:
c) Ota järkevät URLit (permalinks) käyttöön
d) Vaihda teema
e) Varmuuskopioi sisältö
f) Palauta varmuuskopioitu sisältö puhtaaseen WordPress-asennukseen
g) Tee WordPressiin oma teema
h) Asenna WordPressiin plugin (esim Dofollow)
i) Tee WordPressiin oma plugin
j) Lisää kuvia WordPressiin (ja laita tämä toimimaan)
k) Laita WordPress nimipohjaiseen virtuaalipalvelimeen (http://thello.foo tms)
Muita vapaaehtoisia:
l) Asenna Drupal ja kokeile sitä
m) Asenna Joomla ja kokeile sitä
n) Hanki virallinen, selainten hyväksymä TLS-sertifikaatti Let’s Encryptistä
o) Vaikea: Tee esimerkkisivu Python Flaskilla
p) Vaikea: Tee esimerkkisivu Ruby on Rails (tuotantotyyppinen, ei pelkkä yhden käyttäjän testipalvelin)
q) Vaikea: Tee esimerkkisivu Python Django:lla (tuotantotyyppinen, ei pelkkä yhden käyttäjän testipalvelin)

A.) S.) Etusivu käyttäjän kotihakemistoon

Tarkoituksena olisi ensimmäisessä tehtävässä luoda virtuaalipalvelimen kotisivu käyttäjän kotihakemistoon. Siispä otamme ensiksi yhteyttä palvelimeen $ ssh santeri@santerisiirila.me. Kun olemme sisällä voimme aloittaa tekemisen. Kello on 14:41.

Ensiksi luomme uuden uuden kansion, johon haluamme asettaa DocumentRoot-polun lopulta: $ mkdir publicsites. Kansion nimi tosin voi olla mikä tahansa. Sitten voimme käydä säätämässä asetuksia. $ cd /etc/apache2/sites-available. Tänne voimme asettaa uuden ohjauksen. Luomme siis siihen uuden .conf-tiedoston, joka tulee kertomaan uuden polun Apachen sivulle. Näin ainakin muistelin, että se menisi. Loin $ sudo nano publicsite.conf -komennolla tiedoston, joka oli täytetty opettajamme Tero Karvisen mukaan hänen kotisivuiltaan: http://terokarvinen.com/2018/name-based-virtual-hosts-on-apache-multiple-websites-to-single-ip-address. Publicsite.conf näytti lopuksi tältä:

<VirtualHost *:80>
ServerName santerisiirila.me
ServerAlias www.santerisiirila.me
DocumentRoot /home/santeri/publicsites/
<Directory /home/santeri/publicsites/>
Require all granted
</Directory>
</VirtualHost>

Sitten enabloin sivun komennolla $ sudo a2ensite publicsite.conf. Sen jälkeen yritin potkaista demonia uudelleen käyntiin $ systemctl restart apache2, joka normaalisti kysyisi vain salasanaa, mutta nyt sain tällaisen ilmoituksen:

==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ===
Authentication is required to restart 'apache2.service'.
Multiple identities can be used for authentication:
1. santeri,,, (santeri)
2. santeri,,, (santeri)
Choose identity to authenticate as (1-2):

Valitsin tähän “1”, jonka jälkeen kysyi salasanaa. Aloin kirjoittaa salasanaa, mutta sitten asiat menivät ihan sekaisin. Kesken salasanan kirjoitusta sain tällaisen:

Password: Failed to restart apache2.service: Connection timed out
See system logs and 'systemctl status apache2.service' for details.
santeri@ubuntu-s-1vcpu-2gb-fra1-01:/etc/apache2/sites-available$ polkit-agent-helper-1: pam_authenticate

Tämän jälkeen painoin Ctrl + C, että saan tapettua prosessin, mutta silti jokin oli hullusti. En nähnyt enää inputtiani ja kaikki olivat vähän “sekaisin”. Kun laittoi $ ls, niin listaus näytti todella sekavalta. Päätin vain antaa $ exit ja kirjautua jälleen uudestaan koneeseen. Tämän jälkeen kaikki vaikutti taas olevan normaalisti. Nyt sain käynnistettyä demonin normaalisti, mutta laitoin varmuudeksi ihan $ sudo systemctl restart apache2, aiemmin en laittanut sudoa, koska se yleensä kysyy salasanaa kumminkin.

Sitten menin takaisin kotihakemistoon: $ cd /home/santeri/publicsites. Siellä sitten vielä laitoin $ echo moikka kotihakemisto! > index.php. Tämän jälkeen menin Debianillani santerisiirila.me -sivulle. Tässä lopputulos:

Screenshot from 2019-02-09 15-16-02.png

Kaikki toimi kuten pitikin loppujenlopuksi. Kello on 15:16.

A.) Käyttäjien omat kotisivut

Tajusin vasta aiemman kohdan tehtyä, että haluttiinkin ainoastaan jokaiselle käyttäjälle oma kotisivu. Tein siis vahingossa myöhemmän tehtävän aiemmin. Teemme siis nyt ne käyttäjäkohtaiset kotisivut. Kello on 15:20.

Siispä etsin vähän tietoa, koska olen vähän unohtanut, kuinka ne asetukset saatiinkaan päälle. Etsin hakukoneesta “enable user directories apache”. Löysin tämän sivun: https://websiteforstudents.com/enable-userdir-apache2-nginx-ubuntu-17-04-17-10/. Siinä sanotaan, että antaa vain komennon $ sudo a2enmod userdir, jonka jälkeen Apache itse neuvoo käynnistämään demonin uudestaan $ sudo systemctl restart apache2 -komennolla. Tämän jälkeen kävin katsomassa santerisiirila.me-domainissa pyörivän palvelimeni /~santeri-polun. Siellä oli tällainen tilanne:

Screenshot from 2019-02-09 15-31-29.png

Minulla siis oli siellä valmiiksi index-sivu. PHP ei ole enabloitu käyttäjähakemistoissa siispä haluan vielä korjata nopeasti. Etsin taas hakukoneesta “enable php user apache”, josta löytyi tämä Stack Overflow -lanka: https://stackoverflow.com/questions/42654694/enable-php-apache2 Tein kuten langassa sanottiin, mutta php 5 sijasta kirjoitin php 7.2. Eli siis $ sudo a2enmod php7.2. Tuli tällainen ilmoitus:

santeri@ubuntu-s-1vcpu-2gb-fra1-01:/etc/apache2/sites-enabled$ sudo a2enmod php7.2
Considering dependency mpm_prefork for php7.2:
Considering conflict mpm_event for mpm_prefork:
Considering conflict mpm_worker for mpm_prefork:
Module mpm_prefork already enabled
Considering conflict php5 for php7.2:
Module php7.2 already enabled

Siispä menin katsomaan /etc/apache2/mods-available/-kansion. Sieltä etsin php7.2.conf-tiedoston, joka on modin konfiguraatiotiedosto. Katsoin sitä ja alimmat rivit olivat kommentoimatta, jossa juuri luki

# To re-enable PHP in user directories comment the following lines
# (from <IfModule ...> to </IfModule>.) Do NOT set it to On as it
# prevents .htaccess files from disabling it.
<IfModule mod_userdir.c>
<Directory /home/*/public_html>
php_admin_flag engine Off
</Directory>
</IfModule>

Siispä $ sudoedit php7.2.conf. Sieltä vain #-merkillä kommentoimaan viimeiset viisi riviä pois. Sitten vielä viimeiseksi $ sudo systemctl restart apache2, jonka jälkeen lopputulos oli tällainen:

Screenshot from 2019-02-09 15-40-14.png

Melkein ihmettelin, että miksi ei näkynyt lopputulosta PHP-osiosta, mutta sitten tajusin, etten edes tehnyt sitä print()-metodilla. Siispä siinä ainostaan syy. Kaikki toimii kuten pitääkin. Kello on 15:41.

Y.) Murtautumisyritysten tutkiminen

Seuraavassa tehtävässä olisi tarkoitus katsoa VPS-palvelimeni lokeja ja yrittää etsiä sieltä murtautumisyrityksiä. Niitä olisi tarkoitus myös vähän tutkia esimerkiksi geoiplookup-, whois- ja ipcalc-ohjelmilla.

Kirjoitin hakukoneeseen hakusanaksi “cheking breaking attempts linux”, joka antoi minulle tämän postauksen: https://serverfault.com/questions/260706/possible-break-in-attempt-in-var-log-secure-what-does-this-mean

Siinä käyttäjällä on CentOS, mutta varmaankin tapahtuu Ubuntussa lähes samalla tavalla ainakin. Eli hän oli katsonut lokia /var/log/secure. Menen siis itsekin etsimään jotain vastaavaa. $ cd /var/log, niin päästään lokitiedostojen äärelle. Siellä huomasin auth.log-tiedoston. Nimeltään vaikuttaisi oikealta tiedostolta. $ less auth.log. Selasin lokia ja yllätyksekseni sekä kauhukseni eri autentikaatioyritysten määrä oli järkyttävä. Esimerkiksi jos annoin komennon $ less auth.log |grep root, niin tässä oli esimerkkituloksia:

Feb 9 13:59:43 ubuntu-s-1vcpu-2gb-fra1-01 sshd[13751]: PAM 5 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=122.194.229.45 user=root
Feb 9 13:59:47 ubuntu-s-1vcpu-2gb-fra1-01 sshd[13753]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=122.194.229.45 user=root
Feb 9 13:59:50 ubuntu-s-1vcpu-2gb-fra1-01 sshd[13753]: Failed password for root from 122.194.229.45 port 8786 ssh2
Feb 9 14:00:05 ubuntu-s-1vcpu-2gb-fra1-01 sshd[13753]: message repeated 5 times: [ Failed password for root from 122.194.229.45 port 8786 ssh2]
Feb 9 14:00:05 ubuntu-s-1vcpu-2gb-fra1-01 sshd[13753]: error: maximum authentication attempts exceeded for root from 122.194.229.45 port 8786 ssh2 [preauth]
Feb 9 14:00:05 ubuntu-s-1vcpu-2gb-fra1-01 sshd[13753]: Disconnecting authenticating user root 122.194.229.45 port 8786: Too many authentication failures [preauth]
Feb 9 14:00:05 ubuntu-s-1vcpu-2gb-fra1-01 sshd[13753]: PAM 5 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=122.194.229.45 user=root
Feb 9 14:00:10 ubuntu-s-1vcpu-2gb-fra1-01 sshd[13755]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=122.194.229.45 user=root
Feb 9 14:00:12 ubuntu-s-1vcpu-2gb-fra1-01 sshd[13755]: Failed password for root from 122.194.229.45 port 33968 ssh2
Feb 9 14:00:15 ubuntu-s-1vcpu-2gb-fra1-01 sshd[13759]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=112.85.42.232 user=root
Feb 9 14:00:15 ubuntu-s-1vcpu-2gb-fra1-01 sshd[13755]: Failed password for root from 122.194.229.45 port 33968 ssh2
Feb 9 14:00:17 ubuntu-s-1vcpu-2gb-fra1-01 sshd[13759]: Failed password for root from 112.85.42.232 port 20172 ssh2

Nämä olivat vain esimerkkejä. Jos laittoi $ tail -F auth.log, niin tuloksia tuli lähes joka sekunti lisää.

Testataanpa tutkia hieman näitä kyseisiä IP-osoitteita. Ensiksi $ sudo apt install ipcalc. Sitten $ man ipcalc. Tämän jälkeen tiesin, että vain $ ipcalc <osoite>, joten tässä tulokset yhdeltä IP:ltä:

Screenshot from 2019-02-09 16-07-49.png

Nämä tulokset eivät kertoneet minulle pahemmin mitään. Jatketaan tutkimista. Testataan whois-ohjelmaa seuraavaksi. $ sudo apt install whois. $ whois 122.194.229.45. Tällä kertaa tulokset olivatkin mielenkiintoisempia:

Screenshot from 2019-02-09 16-13-20.png

Tällaista tuloksissa esimerkiksi luki. Nähtävästi kiinalaisia, mutta varmaankin käyttävät joten whois-hämäystä, mutta saattaa jotkin tiedoista pitävän paikkaansa.

Katsoin vielä huvikseni toisenkin IP:n, joka oli yrittänyt murtautua:

Screenshot from 2019-02-09 16-21-46.png

Nähtävästi hollantilainen. Voisi ehkä jopa pitää paikkaansa. Yritin vielä katsoa geolookupia, mutta en löytänyt. Vaikka etsin ihan $ apt-cache search lookup geo. Siltikään ei mitään sellaista ohjelmaa löytynyt paketinhallinnasta. Kello on 16:26.

B.) Sivujen tekeminen paikallisesti ja lähetys SCP:llä

Seuraavaksi olisi tarkoitus luoda tiedostot paikallisella koneella ja sitten siirtää ne palvelimelle SCP:llä (https://en.wikipedia.org/wiki/Secure_copy). Muistaakseni tähän tarvittiin SSH-avainpari, joten etsin hakukoneesta ohjeita, kuinka sellainen laitetaan. Tein paikallisella koneella aluksi kyllä SSH-keygenillä itselleni SSH-avaimen, mutta en vain tiennyt, kuinka se otetaan vastaan palvelimella ja tallennetaan. Tein sen siis sen avaimen näin:

$ ssh-keygen 
Generating public/private rsa key pair.
Enter file in which to save the key (/home/santeri/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/santeri/.ssh/id_rsa.
Your public key has been saved in /home/santeri/.ssh/id_rsa.pub.

Menin hakemaan avaimen näin: $ cat /home/santeri/.ssh/id_rsa.pub ja kopioin sen leikepöydälle. Nyt vain miettimään, että mihin se tulee laittaa. Etsin hakukoneesta “add ssh key pair” ja löysin tämän artikkelin https://www.digitalocean.com/community/tutorials/how-to-set-up-ssh-keys–2. Otin sieltä $ cat ~/.ssh/id_rsa.pub | ssh santeri@santerisiirila.me “mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys” komennon, joka ymmärtääkseni lisäsi SSH-avaimen onnistuneesti. Kun testasin kirjautua palvelimelle, niin sen sijaan, että kysyisi salasanaa tunnukseen, niin kysyikin salasanaa avaimeen, joka oli suojattu erillisellä salasanalla. Tämän asetettua pääsin sisälle palvelimelle ja tietääkseni sain SSH-avainparin toimimaan.

Seuraavaksi tein nopeasti, jonkin sivun, jonka voin sitten siirtää SCP:llä.

Näin pari tuntia myöhemmin, niin eihän se lopulta kauhean nopeasti sittenkään sujunut. Yritin väsertää sivua pari tuntia, vaikka halusin vain todella yksinkertaisen sellaisen. Kiitos IDE:n (WebStorm), niin asioiden arvailu oli edes hieman helpompaa.

Nyt olisi tarkoitus siirtää sivusto SCP:llä tuolle palvelimelle. Löysin heti hakukoneesta tällaisen sivun: https://linuxize.com/post/how-to-use-scp-command-to-securely-transfer-files/. Siinä kerrotaan, että siirtäminen tapahtuu ihan vain $ scp <tiedosto> <käyttäjänimi>@<palvelin>:/<hakemisto>. Vaikka minulla on vain yksi tiedosto, niin haluan tehdä niin kuin minulla olisi kokonainen hakemistollinen kopioitavaa. https://serverfault.com/questions/264595/can-scp-copy-directories-recursively Tämän sivun mukaan “-r” olisi avainsana. Yritin scp -r testisivu/ santeri@santerisiirila.me:/publicsites, mutta sain vain virheen: scp: /publicsites: Permission denied. Outoa, koska pääsen ihan ilman salasanaa SSH:lla palvelimelle, koska loin avainparin. Etsin siis tähän vastausta. Löysin vastauksen tältä sivulta https://askubuntu.com/questions/66492/scp-copy-over-ssh-doesnt-work-permission-denied-error-please. Syy oli, että kirjoitin /publicsite, joka tarkoittaisi sitä, että yrittäisin kopioida juurihakemistossa sijaitsevaan publicsites-kansioon tiedostoja. Siispä joko koko polku (/home/santeri/publicsites) tai vain hakemisto (publicsites) ilman juurihakemistoa (/). Loppuun kirjoitetaan tiedostonimi. Tässä siis lopputulos:

Screenshot from 2019-02-09 18-34-37.png

Poistin index.php-tiedoston komennolla $ rm index.php, etteivät nämä kaksi index-sivua mene ristiin.

Sitten vielä visiitti santerisiirila.me-sivulla:

Screenshot from 2019-02-09 18-36-51.png

Se toimii! Tehtävässä meni paljon kauemmin CSS:n kanssa säätämisen takia, joten siksi tässä tehtävässä meni noin 2,5 tuntia. Kello on 18:38.

C. Yksinkertainen PHP-sivu

Seuraavaksi piti vielä tehdä yksinkertainen PHP-sivu. Päätin tehdä tehtävässä ehdotetun IP-näyttäjän. Päätin hakea vähän apuja. Löysin tämän sivun: https://ccm.net/faq/1965-php-how-to-display-ip-address-of-a-visitor. Siinä näytettiin IP:n formaatti paremmin kuin opettajamme ohjeessa (http://terokarvinen.com/2018/aikataulu-linux-palvelimet-ict4tn021-3004-ti-alkukevat-2019-5-op).

Sain IP:n printattua siis näin:

<?php print("$_SERVER[REMOTE_ADDR]");?>

Muutin myös tiedostomuodon .html-muodosta .php-muotoon komennolla $ mv index.html index.php. Tämän jälkeen sivu näytti IP-osoitteen, mutta haluan vielä säätää fonttia suuremmaksi ja paremman näköiseksi. Siispä muokkasin hieman koodia ja lopputulos näytti koodin osalta tältä:

<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>Coming soon...</title>
<style>
body {
background-color: #888888;
}
.main {
display: block;
margin-left: auto;
margin-right: auto;
width: 100%;
}
h1 {

color: #ffffff;
margin-top: 10%;
vertical-align: middle;
font-family: GentiumAlt;
align-items: center;
text-align: center;
}
.ip {
margin-top: 5%;
font-family: Courier;
font-size: 45pt;
text-align: center;
}
</style>
</head>
<body>
<h1>Coming soon... </h1> <img src="https://free-astro.org/images/0/04/Debian_logo.png"> </div> </body> </html>

Sivu toimi mallikkaasti ja näyttää ihan tyylikkäältä. Lopputulosta en viitsi näyttää, koska siinä lukee IP-osoitteeni, mutta voi käydä katsomassa sivulta http://santerisiirila.me/. Tässä tehtävässä meni paljon vähemmän kuin oletin, mutta kiva joskus näinkin päin. Kello on 18:56.

N.) TLS-sertifikaatti

Näissä tehtävissä meni tällä kertaa sen verran vähän aikaa, että päätin tehdä yhden lisätehtävän, jonka samalla koen hyödylliseksi. En välttämättä koe WordPressiä niin hyödyllisenä, vaikka voisi olla joskus ihan käytännöllinen.

Menin Let’s Encryptin sivuille https://letsencrypt.org/getting-started/. Sieltä minut ohjattiin Certbotiin (https://certbot.eff.org/), koska minulla on “Shell access”. Sieltä piti valita alusta (Apache) ja järjestelmä (Ubuntu 18.04 LTS). Tein asennuksen täysin tämän ohjeen mukaan: https://certbot.eff.org/lets-encrypt/ubuntubionic-apache. Eli siis:

$ sudo apt-get update
$ sudo apt-get install software-properties-common
$ sudo add-apt-repository universe
$ sudo add-apt-repository ppa:certbot/certbot
$ sudo apt-get update
$ sudo apt-get install certbot python-certbot-apache 

 

 

Tämän jälkeen käynnistin Certbotin komennolla:

$ sudo certbot --apache

Tämän jälkeen sertifikaattien asennus alkoi. Tässä on terminaalini output ja vastaukset kysymyksiin. Lihavoitan omat vastaukseni erottuvuuden vuoksi. Vastaukset ovat vaikeasti nähtävissä, koska ne ovat yleensä vain kirjaimen tai numeron pituisia.

santeri@ubuntu-s-1vcpu-2gb-fra1-01:~/publicsites$ sudo certbot –apache
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator apache, Installer apache
Enter email address (used for urgent renewal and security notices) (Enter ‘c’ to
cancel): santeri.siirila@gmail.com

– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
Please read the Terms of Service at
https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf. You must
agree in order to register with the ACME server at
https://acme-v02.api.letsencrypt.org/directory
– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
(A)gree/(C)ancel: a

– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
Would you be willing to share your email address with the Electronic Frontier
Foundation, a founding partner of the Let’s Encrypt project and the non-profit
organization that develops Certbot? We’d like to send you email about our work
encrypting the web, EFF news, campaigns, and ways to support digital freedom.
– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
(Y)es/(N)o: n

Which names would you like to activate HTTPS for?
– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
1: santerisiirila.me
2: http://www.santerisiirila.me
– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter ‘c’ to cancel): 1, 2
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for santerisiirila.me
http-01 challenge for http://www.santerisiirila.me
Enabled Apache rewrite module
Waiting for verification…
Cleaning up challenges
Created an SSL vhost at /etc/apache2/sites-available/publicsite-le-ssl.conf
Enabled Apache socache_shmcb module
Enabled Apache ssl module
Deploying Certificate to VirtualHost /etc/apache2/sites-available/publicsite-le-ssl.conf
Enabling available site: /etc/apache2/sites-available/publicsite-le-ssl.conf
Deploying Certificate to VirtualHost /etc/apache2/sites-available/publicsite-le-ssl.conf

Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access.
– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
1: No redirect – Make no further changes to the webserver configuration.
2: Redirect – Make all requests redirect to secure HTTPS access. Choose this for
new sites, or if you’re confident your site works on HTTPS. You can undo this
change by editing your web server’s configuration.
– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
Select the appropriate number [1-2] then [enter] (press ‘c’ to cancel): 2
Enabled Apache rewrite module
Redirecting vhost in /etc/apache2/sites-enabled/publicsite.conf to ssl vhost in /etc/apache2/sites-available/publicsite-le-ssl.conf

– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
Congratulations! You have successfully enabled https://santerisiirila.me and
https://www.santerisiirila.me

You should test your configuration at:
https://www.ssllabs.com/ssltest/analyze.html?d=santerisiirila.me
https://www.ssllabs.com/ssltest/analyze.html?d=www.santerisiirila.me

Kun asennus oli valmis, niin kävin katsomassa sivuni, mutta en saanut yhteyttä enää. Odotan jonkin aikaa, jos se olisi vain väliaikainen yhteysvirhe. Toivottavasti nyt jokin ei levinnyt aivan totaalisesti. Ping toimii hyvin, mutta selain ei vain saa yhteyttä. Veikkaan, että Certbot muutti konfiguraatioita niin, että yhteyttä ei voida muodostaa. Kello on paussin kohdalla 19:28.

Taukoa pidin noin 15 minuuttia ja mietitytti, että miksei asiat toimi. Ping toimi, mutta ei HTTP-requestit. Sitten se valkeni minulle. Kävin katsomassa /etc/apache2/sites-available/, jonne oli generoitu publicsite-le-ssl.conf-tiedosto. En tiennyt, että SSL vaatii TCP-porttia 443 auki toimiakseen. Siispä, kun en saanut yhteyttä, niin palvelimeltani vain annoin komennon $ sudo ufw allow 443/tcp, jolla saadaan avattua tuo kyseinen portti. Käynnistin demonin vielä uudestaan $ sudo systemctl restart apache2, jonka jälkeen tulos oli tällainen:

Screenshot from 2019-02-09 20-00-43

Tadaa! Sivuillani on nyt toimivat sertifikaatit.

Tehtävän lopetettua kello on 20:03.

Tehtäviin meni siis kokonaisuudessaan noin 6 tuntia.

Leave a comment