OpenPGP/GnuPG :: Certyfikaty x509

Szyfrowanie

Przesyłanie danych przez Internet pod względem ich bezpieczeństwa przypomina przesyłanie ich przy pomocy kartek pocztowych - każda osoba (serwer/router) pośrednicząca w przekazywaniu może podejrzeć zawartość, ale zrobić to może także osoba będąca dostatecznie blisko i posiadająca np. lornetkę. Dlatego przy poufnych danych stosuje się ich szyfrowanie. Kolejną kwestia jest łatwość zmiany danych będących w postaci cyfrowej tudzież wyparcia się ich autentyczności/autorstwa - stąd bardzo pokrewna szyfrowaniu technika podpisu cyfrowego. Zobacz także skrypt eksportujący dane kryptograficzne (i nie tylko) - CommonsConfig-addionals.sh

OpenPGP/GnuPG

Do szyfrowania oraz podpisywania danych możemy skorzystać GnuPG.

Aby wygenerować klucze uruchamiamy gpg --gen-key, aby dodać dodatkowy identyfikator do naszego klucza (przydatne gdy chcemy nim podpisywać np. maile wysyłane z różnych adresów uruchamiamy gpg --edit-key podany.przy.generacji@email.identyfikujacy.klucz i w uzyskanej linii poleceń wydajemy adduid.

Aby wyeksportować nasz klucz publiczny używamy komendy gpg --armour --output publiczny.gpg --export podany.przy.generacji@email.identyfikujacy.klucz, aby wyeksportować klucz prywatny używamy opcji gpg --list-secret-keys. Możemy także uzyskać bardzo streszczony klucz publiczny (pozbawiony wszelkich podpisów innych osób) - w tym celu należy wygenerować go na podstawie klucza prywatnego w następujący sposób:

	mkdir gpg-export-tmp-dir
	chmod 700 gpg-export-tmp-dir
	gpg -a --export-secret-keys > gpg-export-tmp-dir/sec.asc
	gpg --homedir gpg-export-tmp-dir --import gpg-export-tmp-dir/sec.asc
	gpg --homedir gpg-export-tmp-dir -a --export > public.asc
	rm -fr gpg-export-tmp-dir

Aby zaimportować czyjś klucz gpg --import publiczny.gpg.

Aby zaszyfrować dane wysyłane do kogoś jego kluczem publicznym: gpg --output plik_wyjsciowy --encrypt --recipient identyfikator@email.odbiorcy plik_wejsciowy, aby odszyfrować odebrane dane szyfrowane naszym kluczem publicznym: gpg --output plik_wyjsciowy --decrypt plik_wejsciowy. Gdy dysponujemy zestawem klucza publicznego i prywatnego w formacie binarnym możemy to uczynić także bez importowania tych kluczy: gpg --keyring klucz_publiczny --secret-keyring klucz_prywatny --decrypt wiadomosc_do_odszyfrowania. Jeżeli chcemy odszyfrować dane mając klucz prywatny w postaci ASCII nie obędzie się bez jego zaimportowania, można to jednak zrobić do tymczasowego pliku:

	mkdir gpg-decrypt-tmp-dir
	chmod 700 gpg-decrypt-tmp-dir
	gpg --homedir gpg-decrypt-tmp-dir --import secret.asc
	gpg --homedir gpg-decrypt-tmp-dir --decrypt zaszyfrowany.txt > odszyfrowany.txt
	rm -fr gpg-decrypt-tmp-dir

Aby wygenerować podpis do wiadomości: gpg --output wygenerowany_podpis.sig --detach-sig plik_wejsciowy.

Zobacz też: Architektura klucza publicznego w Gnu Privacy Guard (GPG) oraz klucze ssh, VPN.

Certyfikaty x509

Do szyfrowania i podpisywania możemy korzystać także z z certyfikatów takich jak wykorzystywane w połączeniach SSL. Istnieje kilka dróg generowania certyfikatów i kluczy tego typu. Możemy to zrobić np. w następujący sposób: openssl req -new -x509 -days 4095 -newkey rsa:2048 -keyout ca_key.pem -out ca_cert.pem, wygenerowany zostanie certyfikat podpisany przez samego siebie (opcja -x509), jeżeli dodana byłaby opcja -nodes klucz prywatny nie byłby zabezpieczony hasłem (jest to przydatne przy generowaniu certyfikatów dla serwerów - szyfrowanie www, poczty itp.).

Wygenerowany w sposób opisany powyżej zestaw certyfikatu i klucza możemy używać od razu do szyfrowania bądź do podpisywania próśb o certyfikat generowanych komendą: openssl req -new -keyout server.key -out server.key (UWAGA: w przypadku certyfikatów dla serwerów w "COMMON NAME" nazwa domeny dla której jest certyfikat, można użyć *.domena aby pasował do wszystkich hostów w domenie). Prośbę taką możemy przekazać do podpisu jakiemuś prawdziwemu CA lub podpisać sobie sami (wygenerowanym wcześniej kluczem): openssl x509 -req -out server.crt -in server.key -CA ca_cert.pem -CAkey ca_key.pem -CAcreateserial -days 365. Na koniec możemy usunąć hasło z klucza prywatnego (przydatne dla serwerów): openssl rsa -in server.key -out server.key.

Na potrzeby wielu programów konieczne będzie wyeksportowanie zestawu klucza i certyfikatu do formatu PKCS#12 - openssl pkcs12 -export -in cert1_cert.pem -inkey cert1_key.pem -out cert1.p12. Klucz taki możemy zaimportować np. do gpgsm - gpgsm --import cert1.p12 (wcześniej odpalamy gpg-agent --daemon i eksportujemy tak jak sugeruje GPG_AGENT_INFO). Pozwoli to na włączenie funkcjonalności S/MIME w kmail'u (wymagane pakiety gpgsm i kleopatra), w tym celu należy ponadto zaimportować certyfikaty CA - gpgsm --import /etc/ssl/certs/ca-certificates.crt i zakwalifikować wszystkie te (nasz i CA) certyfikaty jako zaufane - gpgsm -k | grep fingerprint | while read tmp fpr; do echo "$fpr S relax"; done > ~/.gnupg/trustlist.txt

Problem wielu domen

Znanym problemem związanym z certyfikatami SSL jest problem obsLugi wielu domen na jednym zestawie ip-port. Pierwotnie protokół przywiązał do takiego zestawy jeden cetryfikat co uniemożliwiaLo stawiania name based virtual host z ssl-em. Obecnie stosowane jest kilka rozwiązań tego problemu (jednak wszystkie miewają jakieś ograniczenia ze względu na kompatybilność z starszym oprogramowaniem):

Przykładowa metoda generacji samopodpisanego certyfikatu mającego kilka CN i wpisów "DNS":

openssl genrsa -out server.key 1024
openssl req -new -config server.cfg -key server.key -out server.csr

# uzyskane żądanie certyfikatu możemy obejrzeć przy pomocy
# openssl req -in server.csr -text -noout

# samopodpisanie certyfikatu
openssl x509 -req -in server.csr -signkey server.key -extfile server.cfg -extensions v3_req -days 4095 -text -out server.crt

Wykorzystywany plik konfiguracyjny server.cfg ma postać:

[ req ]
default_bits            = 1024
distinguished_name      = req_distinguished_name
req_extensions          = v3_req
prompt                  = no

[ v3_req ]
basicConstraints        = CA:FALSE
keyUsage                = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName          = @alt_names


[ req_distinguished_name ]
C=PL
L=miasto
O=organizacja
OU=jednostka
emailAddress=admin@example.org


[ alt_names ]
DNS.0 = sub.domena1.tld
DNS.1 = domena2.tld

[ req_distinguished_name ]
0.CN=sub.domena1.tld
1.CN=domena2.tld


Copyright (c) 1999-2015, Robert Paciorek (http://www.opcode.eu.org/), BSD/MIT-type license


Redystrybucja wersji źródłowych i wynikowych, po lub bez dokonywania modyfikacji JEST DOZWOLONA, pod warunkiem zachowania niniejszej informacji o prawach autorskich. Autor NIE ponosi JAKIEJKOLWIEK odpowiedzialności za skutki użytkowania tego dokumentu/programu oraz za wykorzystanie zawartych tu informacji.

This text/program is free document/software. Redistribution and use in source and binary forms, with or without modification, ARE PERMITTED provided save this copyright notice. This document/program is distributed WITHOUT any warranty, use at YOUR own risk.

Valid XHTML 1.1 Dokument ten (URL: http://www.opcode.eu.org/usage_and_config/network_services/cryptography) należy do serwisu OpCode. Autorem tej strony jest Robert Paciorek, wszelkie uwagi proszę kierować na adres e-mail serwisu: webmaster@opcode.eu.org.
Data ostatniej modyfikacji artykulu: '2015-10-19 21:41:37 (UTC)' (data ta może być zafałszowana niemerytorycznymi modyfikacjami artykułu).