Sådan bruges HTTPS på Arch Linux Webserver

Forudsætninger

• En Vultr-server, der kører up to date Arch Linux (se denne artikel .)
• En kørende webserver, enten Apache eller Nginx
• Sudo adgang
  • Kommandoer, der kræves for at blive kørt som root, er præfikset med #, og dem, der kan køres som en almindelig bruger af $. Den anbefalede måde at køre kommandoer på som root er at, som en almindelig bruger, præfikse hver af dem med sudo.
• Få en teksteditor installeret, og vær fortrolig med den, såsom vi, vim, nano, emacs eller en anden lignende editor.

Sikker betjening via HTTPS

Servering af indhold via HTTPS kan bruge ekstrem stærk kryptering, så ingen, der opsnapper trafik mellem brugeren og webserveren, kan læse det. Det krypterer ikke kun selve trafikken, men også den URL, der tilgås, som ellers kan afsløre information. I nogen tid har Google delvist bestemt søgerangeringer baseret på, om en side bruger HTTPS, som en del af initiativet HTTPS Everywhere.

Bemærk : et DNS-opslag afslører det domænenavn, der forbindes til, men hele URL-adressen afsløres ikke under denne proces.

Få SSL/TLS-certifikat

Teknisk set erstattede TLS SSL for HTTPS-certifikater, men de fleste steder fortsatte man simpelthen med at kalde TLS-certifikater med det mere populære udtryk SSL-certifikater. Efter almindelig brug vil denne vejledning gøre det samme.

For at bruge HTTPS skal din webserver bruge en privat nøgle ( .key) til privat brug og et certifikat ( .crt) til offentlig deling, som inkluderer en offentlig nøgle. Et certifikat skal underskrives. Du kan selv underskrive det, men moderne browsere vil klage over, at de ikke genkender underskriveren. For eksempel vil Chrome vise: Your connection is not private. Attackers might be trying to steal your information... NET::ERR_CERT_AUTHORITY_INVALID. Hvis kun en privat gruppe mennesker vil bruge hjemmesiden, kan dette være acceptabelt, fordi browsere vil tillade en måde at fortsætte. I Chrome skal du f.eks. klikke på "Avanceret" og derefter "Fortsæt til... (usikker)"; det vil stadig vise "Ikke sikkert" og strege "https".

Bemærk, at denne proces vil bede dig om dit land, stat/forsyn, lokalitet, organisation, organisationsenhed og almindelige navne samt din e-mailadresse; som alle er tilgængelige i enhvers browser, der opretter forbindelse til dit websted via HTTPS.

Bemærk også, at hvis du giver virtuelle værtscertifikater, skal du angive forskellige filnavne nedenfor og pege på dem i dine virtuelle værtskonfigurationer.

Skift til den korrekte mappe til din webserver.

Hvis du har installeret Apache:

$ cd /etc/httpd/conf

Hvis du har installeret Nginx:

$ cd /etc/nginx

Når du er i den korrekte mappe, skal du generere en privat nøgle ( server.key) og et selvsigneret certifikat ( server.crt):

# openssl req -new -x509 -nodes -newkey rsa:4096 -keyout server.key -out server.crt -days 825

Indstil skrivebeskyttede tilladelser, og lad kun den private nøgle læses med root:

# chmod 400 server.key
# chmod 444 server.crt

Alternativt kan du få et certifikat underskrevet af en betroet certifikatmyndighed. Du kan betale forskellige virksomheder (certifikatmyndigheder) for at underskrive dit certifikat for dig. Når man overvejer certifikatmyndigheder, kan det være vigtigt at se nærmere på, hvilke browsere og hvilke versioner der vil genkende dem. Nogle nyere certifikatmyndigheder anerkendes muligvis ikke som mere officielle end et selvsigneret certifikat på gamle browserversioner.

Du har typisk ikke kun brug for en offentlig IP-adresse, men også et domænenavn. Nogle certifikatmyndigheder kan udstede et certifikat til en offentlig IP-adresse, men det bliver sjældent gjort.

Mange udbydere tilbyder en gratis 30 dages prøveperiode, som anbefales til at starte med, så du kan sikre dig, at processen fungerer for dig, før du betaler for den. Priserne kan variere fra et par dollars om året til hundredvis, afhængigt af hvilken type det er og muligheder såsom flere domæner eller underdomæner. Et standardcertifikat vil kun angive, at den underskrivende myndighed har bekræftet, at den person, der modtager certifikatet, kan foretage ændringer på domænet. Et udvidet valideringscertifikat vil også angive, at underskrivermyndigheden har udført en vis due diligence-undersøgelse af anmoderen og vil i moderne browsere vise en grøn bjælke i eller i nærheden af ​​URL'en. Når du skal verificere, at du kan foretage ændringer på domænet, vil nogle underskrivende myndigheder kræve, at du modtager e-mail på en vigtig klingende adresse på domænenavnet, som f.eks.[email protected]. Mange tilbyder alternativ verifikation, såsom at give dig en fil til at placere på din server, såsom at placere deres fil i /srv/http/.well-known/pki-validation/for Apache eller /usr/share/nginx/html/.well-known/pki-validation/for Nginx, for enkelt hosting mappe konfigurationer; eller midlertidigt oprette en CNAME-post, de giver dig i dit domænes DNS-registreringer.

Den underskrivende myndighed, du vælger, kan have lidt forskellige trin, men de fleste vil acceptere følgende procedure:

Generer en privat nøgle i den rigtige mappe ( server.key):

# openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:4096 -out server.key

Indstil den private nøgle til skrivebeskyttet, kun med root:

# chmod 400 server.key

Generer en anmodning om certifikatsignering ( server.csr). Du skal Common Nameindtaste dit domænenavn, når det beder dig om , og du kan lade udfordringsadgangskoden være tom:

# openssl req -new -sha256 -key server.key -out server.csr

Indstil anmodningen om certifikatsignering til skrivebeskyttet, kun via root:

# chmod 400 server.csr

Se indholdet af anmodningen om certifikatsignering. Denne information er base64-kodet, så den ser ud som tilfældige tegn:

# cat server.csr
-----BEGIN CERTIFICATE REQUEST-----
.....
-----END CERTIFICATE REQUEST-----

Gå gennem din underskriftsmyndigheds proces, og når du bliver bedt om at indsætte dit CSR, kopier og indsæt hele denne fil inklusive -----linjerne. Afhængigt af den underskrivende myndighed, du har valgt, og typen af ​​certifikat, kan de straks give dig det underskrevne certifikat, eller det kan tage et antal dage. Når de giver dig det underskrevne certifikat, kopiere det (herunder -----BEGIN CERTIFICATE-----og -----END CERTIFICATE-----linjer) i en fil med navnet server.crt, i den rigtige mappe, givet ovenfor for din webserver, og sæt den til read-only:

# chmod 444 server.crt

Konfigurer din webserver til at bruge den private nøgle og certifikatet

Hvis du bruger en firewall, skal du aktivere indgående TCP-trafik til port 443.

Til Apache

Rediger /etc/httpd/conf/httpd.confog fjern kommentarer til disse linjer:

LoadModule ssl_module modules/mod_ssl.so
LoadModule socache_shmcb_module modules/mod_socache_shmcb.so
Include conf/extra/httpd-ssl.conf

Bemærk, at hvis du bruger virtuelle værter, vil ovenstående ændring /etc/httpd/conf/httpd.confbruge det samme certifikat på alle værter. For at give hver vært sit eget certifikat for at undgå, at browsere klager over, at certifikatet ikke matcher domænenavnet, skal du redigere hver af deres konfigurationsfiler for /etc/httpd/conf/vhosts/at pege på dets eget certifikat og private nøgle:

• Skift <VirtualHost *:80>til <VirtualHost *:80 *:443>.

• Inden for VirtualHostsektionen skal du tilføje følgende:

  SSLEngine on
  SSLCertificateFile "/etc/httpd/conf/YOUR-DOMAIN-NAME.com.crt"
  SSLCertificateKeyFile "/etc/httpd/conf/YOUR-DOMAIN-NAME.com.key"
  

Genstart Apache:

# systemctl restart httpd

Til Nginx

Rediger /etc/nginx/nginx.confog nær bunden, fjern kommentering af HTTPS serverafsnittet og skift linjerne til følgende:

ssl_certificate      server.crt;
ssl_certificate_key  server.key;
root                /usr/share/nginx/html;

Bemærk, at hvis du bruger virtuelle værter, vil ændringen ovenfor /etc/nginx/nginx.confsende alle værter til den placering. For at give hver vært sit eget certifikat, skal du redigere hver af deres konfigurationsfiler for /etc/nginx/sites-enabled/at have en ekstra serverblok til at pege på sit eget certifikat og private nøgle:

server {
    listen 443 ssl;
    server_name YOUR-DOMAIN-NAME.com;

    ssl_certificate      YOUR-DOMAIN-NAME.com.crt;
    ssl_certificate_key  YOUR-DOMAIN-NAME.com.key;

    ssl_session_cache   shared:SSL:1m;
    ssl_session_timeout 5m;

    ssl_ciphers  HIGH:!aNULL:!MD5;
    ssl_prefer_server_ciphers  on;

    location / {
        root /usr/share/nginx/YOUR-DOMAIN-NAME.com;
        index  index.html index.htm;
    }
}

Genstart Nginx:

# systemctl restart nginx