Jak utworzyć samopodpisany certyfikat za pomocą OpenSSL

1291

Dodam obsługę HTTPS do wbudowanego urządzenia z systemem Linux. Próbowałem wygenerować samopodpisany certyfikat, wykonując następujące czynności:

openssl req -new > cert.csr
openssl rsa -in privkey.pem -out key.pem
openssl x509 -in cert.csr -out cert.pem -req -signkey key.pem -days 1001
cat key.pem>>cert.pem

To działa, ale pojawiają się pewne błędy, na przykład w Google Chrome:

Prawdopodobnie nie jest to strona, której szukasz!
Certyfikat bezpieczeństwa tej witryny nie jest zaufany!

Czy coś brakuje? Czy to właściwy sposób na zbudowanie certyfikatu z podpisem własnym?

michelemarcon
źródło
40
Certyfikaty z podpisem własnym są uważane za niebezpieczne dla Internetu. Firefox będzie traktował witrynę jako niepoprawny certyfikat, a Chrome będzie działał tak, jakby połączenie było zwykłym HTTP. Więcej informacji: gerv.net/security/self-signed-certs
użytkownik1202136
34
Musisz zaimportować swój certyfikat CA do przeglądarki i powiedzieć przeglądarkom, że ufasz certyfikatowi - lub - podpisaj go przez jedną z dużych organizacji, za które nie płacisz za nic, którym zaufały już przeglądarki - lub zignoruj ​​ostrzeżenie i kliknij przeszłości Sam lubię ostatnią opcję.
trojanfoe
12
Nie należy używać „standardowych” ustawień OpenSSL w ten sposób. Jest tak, ponieważ nie można umieszczać nazw DNS w alternatywnej nazwie podmiotu (SAN). Musisz podać plik konfiguracyjny z alternate_namessekcją i przekazać go z -configopcją. Ponadto umieszczenie nazwy DNS we wspólnej nazwie (CN) jest przestarzałe (ale nie zabronione) zarówno przez IETF, jak i fora CA / Browser. Każda nazwa DNS w CN musi być również obecna w sieci SAN. Nie ma możliwości uniknięcia korzystania z SAN. Zobacz odpowiedź poniżej.
jww
5
Oprócz komentarza @jww. W maju 2017 r. Chrome nie akceptuje już certyfikatów SAN (emtpy): „Certyfikat dla tej witryny nie zawiera rozszerzenia alternatywnej nazwy podmiotu zawierającego nazwę domeny lub adres IP”.
GerardJP,
6
Obecnie, dopóki twój serwer WWW jest dostępny przez FQDN na porcie 80 przez Internet, możesz korzystać z LetsEncrypt i otrzymywać bezpłatne pełne certyfikaty CA (ważne przez 90 dni, odnowienie można zautomatyzować), które nie będą wyświetlać żadnych ostrzeżeń przeglądarki / wiadomości. www.letsencrypt.com
barny

Odpowiedzi:

2130

Możesz to zrobić za pomocą jednego polecenia:

openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365

Możesz także dodać -nodes(skrót od no DES), jeśli nie chcesz chronić swojego klucza prywatnego hasłem. W przeciwnym razie pojawi się monit o podanie hasła „co najmniej 4-znakowego”.

daysParametr (365) można zastąpić dowolną liczbą wpłynąć na datę ważności. Następnie wyświetli monit o podanie nazwy kraju, ale możesz po prostu nacisnąć Enteri zaakceptować wartości domyślne.

Dodaj, -subj '/CN=localhost'aby ukryć pytania dotyczące zawartości certyfikatu (zamień localhostna żądaną domenę).

Certyfikaty z podpisem własnym nie są sprawdzane przez jakąkolwiek stronę trzecią, chyba że wcześniej zaimportujesz je do przeglądarek. Jeśli potrzebujesz większego bezpieczeństwa, powinieneś użyć certyfikatu podpisanego przez urząd certyfikacji (CA).

Diego Woitasen
źródło
8
Dla każdego, kto jest zainteresowany, oto dokumentacja , jeśli chcesz coś zweryfikować samodzielnie.
17
W jaki sposób podpisywanie z firmą zewnętrzną zapewnia większe bezpieczeństwo?
James Mills,
201
Dla każdego, kto używa tego w automatyzacji, oto wszystkie typowe parametry dla tego tematu:-subj "/C=US/ST=Oregon/L=Portland/O=Company Name/OU=Org/CN=www.example.com"
Alex S
16
@JamesMills Mam na myśli, pomyśl o tym - jeśli podejrzany facet z „darmowym cukierkiem” napisanym z boku jego furgonetki zaprasza cię do środka, to całkowicie pomyślisz dwa razy i będziesz się tego pilnował - ale jeśli ktoś, komu ufasz - tak naprawdę naprawdę - jest taki, jak „naw człowieku, on jest legalny”, będziesz o tym wszystkim za darmo.
BrainSlugs83
73
Pamiętaj, aby użyć -sha256do wygenerowania certyfikatu opartego na SHA-256.
Gea-Suan Lin
534

Czy coś brakuje? Czy to właściwy sposób na zbudowanie certyfikatu z podpisem własnym?

Łatwo jest utworzyć samopodpisany certyfikat. Wystarczy użyć openssl reqpolecenia. Stworzenie takiego, które może być wykorzystywane przez największy wybór klientów, takich jak przeglądarki i narzędzia wiersza poleceń, może być trudne.

Jest to trudne, ponieważ przeglądarki mają własny zestaw wymagań i są bardziej restrykcyjne niż IETF . Wymagania stosowane przez przeglądarki są dokumentowane na forach CA / Browser (patrz odnośniki poniżej). Ograniczenia występują w dwóch kluczowych obszarach: (1) kotwice zaufania i (2) nazwy DNS.

Nowoczesne przeglądarki (takie jak Warez, którego używamy w 2014/2015 r.) Chcą certyfikatu, który łączy się z kotwicą zaufania, i chcą, aby nazwy DNS były prezentowane w określony sposób w certyfikacie. Przeglądarki aktywnie działają na podstawie certyfikatów serwerów z podpisem własnym.

Niektóre przeglądarki nie ułatwiają importu certyfikatu serwera z podpisem własnym. W rzeczywistości nie można tego zrobić za pomocą niektórych przeglądarek, takich jak przeglądarka Androida. Zatem kompletnym rozwiązaniem jest stać się własnym autorytetem.

W przypadku braku stania się własnym autorytetem, musisz poprawnie ustawić nazwy DNS, aby dać certyfikatowi największą szansę na sukces. Ale zachęcam cię, abyś stał się swoim własnym autorytetem. Łatwo jest stać się własnym autorytetem i ominie on wszystkie problemy związane z zaufaniem (komu lepiej zaufać niż tobie?).


Prawdopodobnie nie jest to strona, której szukasz!
Certyfikat bezpieczeństwa tej witryny nie jest zaufany!

Wynika to z faktu, że przeglądarki używają wstępnie zdefiniowanej listy kotwic zaufania do sprawdzania poprawności certyfikatów serwerów. Samopodpisany certyfikat nie łączy się z zaufaną kotwicą.

Najlepszym sposobem na uniknięcie tego jest:

  1. Utwórz własny organ (tj. Zostań urzędem certyfikacji )
  2. Utwórz żądanie podpisania certyfikatu (CSR) dla serwera
  3. Podpisz CSR serwera za pomocą klucza CA
  4. Zainstaluj certyfikat serwera na serwerze
  5. Zainstaluj certyfikat CA na kliencie

Krok 1 - Utworzenie własnego urzędu oznacza po prostu utworzenie certyfikatu z podpisem własnym CA: truei właściwego użycia klucza. Oznacza to, że przedmiotowe a Emitent jest ten sam podmiot, CA ma wartość true w podstawowe ograniczenia (to powinno być również oznaczona jako krytyczna), klucz wykorzystywany jest keyCertSigni crlSign(jeśli używasz CRL) i Subject Key Identifier (SKI) jest taki sam jak identyfikator klucza urzędu (AKI).

Aby stać się własnym urzędem certyfikacji, zobacz * W jaki sposób podpisujesz wniosek o podpisanie certyfikatu w swoim urzędzie certyfikacji? na przepełnienie stosu. Następnie zaimportuj swój CA do Trust Store używanego przez przeglądarkę.

Kroki 2–4 są mniej więcej tym, co robisz teraz dla publicznego serwera, gdy rejestrujesz usługi urzędu certyfikacji, takiego jak Startcom lub CAcert . Kroki 1 i 5 pozwalają uniknąć autorytetu osoby trzeciej i działać jako własny autorytet (komu lepiej zaufać niż tobie?).

Następnym najlepszym sposobem uniknięcia ostrzeżenia przeglądarki jest zaufanie do certyfikatu serwera. Ale niektóre przeglądarki, takie jak domyślna przeglądarka Androida, nie pozwalają na to. Więc nigdy nie będzie działać na platformie.

Problem przeglądarek (i innych podobnych aplikacji klienckich) nie ufających certyfikatom z podpisem własnym będzie dużym problemem w Internecie przedmiotów (IoT). Na przykład, co się stanie po podłączeniu do termostatu lub lodówki w celu zaprogramowania? Odpowiedź brzmi: nic dobrego, jeśli chodzi o wrażenia użytkownika.

Grupa robocza WebAppSec W3C zaczyna przyglądać się temu problemowi. Zobacz na przykład Propozycja: Oznaczanie HTTP jako niezabezpieczonego .


Jak utworzyć samopodpisany certyfikat za pomocą OpenSSL

Poniższe polecenia i plik konfiguracyjny tworzą samopodpisany certyfikat (pokazuje również, jak utworzyć żądanie podpisania). Różnią się one od innych odpowiedzi pod jednym względem: nazwy DNS używane dla certyfikatu z podpisem własnym znajdują się w alternatywnej nazwie podmiotu (SAN) , a nie w nazwie zwykłej (CN) .

Nazwy DNS są umieszczane w sieci SAN poprzez plik konfiguracyjny z linią subjectAltName = @alternate_names(nie ma sposobu, aby to zrobić za pomocą wiersza poleceń). Następnie alternate_namesw pliku konfiguracyjnym znajduje się sekcja (należy ją dostosować do własnych upodobań):

[ alternate_names ]

DNS.1       = example.com
DNS.2       = www.example.com
DNS.3       = mail.example.com
DNS.4       = ftp.example.com

# Add these if you need them. But usually you don't want them or
#   need them in production. You may need them for development.
# DNS.5       = localhost
# DNS.6       = localhost.localdomain
# IP.1        = 127.0.0.1
# IP.2        = ::1

Ważne jest, aby umieścić nazwę DNS w sieci SAN, a nie w CN, ponieważ zarówno IETF, jak i fora CA / Browser określają tę praktykę. Określają również, że nazwy DNS w CN są przestarzałe (ale nie zabronione). Jeśli umieścisz nazwę DNS w CN, musi ona zostać uwzględniona w sieci SAN zgodnie z zasadami CA / B. Nie możesz więc uniknąć używania alternatywnej nazwy podmiotu.

Jeśli nie umieścisz nazw DNS w sieci SAN, certyfikat nie będzie sprawdzany pod kątem przeglądarki i innych programów użytkownika zgodnych z wytycznymi CA / Browser Forum.

Powiązane: przeglądarki przestrzegają zasad CA / Browser Forum; a nie zasady IETF. Jest to jeden z powodów, dla których certyfikat utworzony za pomocą OpenSSL (który zwykle jest zgodny z IETF) czasami nie sprawdza się w przeglądarce (przeglądarki stosują się do CA / B). Są to różne standardy, mają różne zasady wydawania i różne wymagania dotyczące walidacji.


Utwórz samopodpisany certyfikat (zauważ dodanie -x509opcji):

openssl req -config example-com.conf -new -x509 -sha256 -newkey rsa:2048 -nodes \
    -keyout example-com.key.pem -days 365 -out example-com.cert.pem

Utwórz prośbę o podpisanie (zauważ brak -x509opcji):

openssl req -config example-com.conf -new -sha256 -newkey rsa:2048 -nodes \
    -keyout example-com.key.pem -days 365 -out example-com.req.pem

Wydrukuj certyfikat z podpisem własnym :

openssl x509 -in example-com.cert.pem -text -noout

Wydrukuj prośbę o podpisanie :

openssl req -in example-com.req.pem -text -noout

Plik konfiguracyjny (przekazany przez -configopcję)

[ req ]
default_bits        = 2048
default_keyfile     = server-key.pem
distinguished_name  = subject
req_extensions      = req_ext
x509_extensions     = x509_ext
string_mask         = utf8only

# The Subject DN can be formed using X501 or RFC 4514 (see RFC 4519 for a description).
#   Its sort of a mashup. For example, RFC 4514 does not provide emailAddress.
[ subject ]
countryName         = Country Name (2 letter code)
countryName_default     = US

stateOrProvinceName     = State or Province Name (full name)
stateOrProvinceName_default = NY

localityName            = Locality Name (eg, city)
localityName_default        = New York

organizationName         = Organization Name (eg, company)
organizationName_default    = Example, LLC

# Use a friendly name here because it's presented to the user. The server's DNS
#   names are placed in Subject Alternate Names. Plus, DNS names here is deprecated
#   by both IETF and CA/Browser Forums. If you place a DNS name here, then you
#   must include the DNS name in the SAN too (otherwise, Chrome and others that
#   strictly follow the CA/Browser Baseline Requirements will fail).
commonName          = Common Name (e.g. server FQDN or YOUR name)
commonName_default      = Example Company

emailAddress            = Email Address
emailAddress_default        = [email protected]

# Section x509_ext is used when generating a self-signed certificate. I.e., openssl req -x509 ...
[ x509_ext ]

subjectKeyIdentifier        = hash
authorityKeyIdentifier    = keyid,issuer

# You only need digitalSignature below. *If* you don't allow
#   RSA Key transport (i.e., you use ephemeral cipher suites), then
#   omit keyEncipherment because that's key transport.
basicConstraints        = CA:FALSE
keyUsage            = digitalSignature, keyEncipherment
subjectAltName          = @alternate_names
nsComment           = "OpenSSL Generated Certificate"

# RFC 5280, Section 4.2.1.12 makes EKU optional
#   CA/Browser Baseline Requirements, Appendix (B)(3)(G) makes me confused
#   In either case, you probably only need serverAuth.
# extendedKeyUsage    = serverAuth, clientAuth

# Section req_ext is used when generating a certificate signing request. I.e., openssl req ...
[ req_ext ]

subjectKeyIdentifier        = hash

basicConstraints        = CA:FALSE
keyUsage            = digitalSignature, keyEncipherment
subjectAltName          = @alternate_names
nsComment           = "OpenSSL Generated Certificate"

# RFC 5280, Section 4.2.1.12 makes EKU optional
#   CA/Browser Baseline Requirements, Appendix (B)(3)(G) makes me confused
#   In either case, you probably only need serverAuth.
# extendedKeyUsage    = serverAuth, clientAuth

[ alternate_names ]

DNS.1       = example.com
DNS.2       = www.example.com
DNS.3       = mail.example.com
DNS.4       = ftp.example.com

# Add these if you need them. But usually you don't want them or
#   need them in production. You may need them for development.
# DNS.5       = localhost
# DNS.6       = localhost.localdomain
# DNS.7       = 127.0.0.1

# IPv6 localhost
# DNS.8     = ::1

W przypadku Chrome może być konieczne wykonanie następujących czynności. W przeciwnym razie Chrome może złożyć skargę, że nazwa pospolita jest nieprawidłowa ( ERR_CERT_COMMON_NAME_INVALID) . W tym przypadku nie jestem pewien, jaki jest związek między adresem IP w sieci SAN a CN.

# IPv4 localhost
# IP.1       = 127.0.0.1

# IPv6 localhost
# IP.2     = ::1

Istnieją inne zasady dotyczące obsługi nazw DNS w certyfikatach X.509 / PKIX. Zasady znajdują się w tych dokumentach:

RFC 6797 i RFC 7469 są wymienione, ponieważ są bardziej restrykcyjne niż inne dokumenty RFC i CA / B. RFC 6797 i 7469 również nie pozwalają na adres IP.

jww
źródło
4
Czy w alternate_namessekcji można używać symboli wieloznacznych ? W szczególności subdomeny. Mam pytanie odnoszące się do tej odpowiedzi tutaj: serverfault.com/questions/711596/…
LeonardChallis
3
Właśnie odpowiedziałem na jego konkretne pytanie. Myślę, że dodanie tego długiego opisu zabezpieczeń nie ma sensu, gdy odpowiedź była tak prosta
Diego Woitasen
14
@diegows - twoja odpowiedź nie jest kompletna lub poprawna. Powód, dla którego jest niepoprawny, został omówiony w długim poście, którego nie chcesz czytać :)
jww
1
Dzięki! Uznałem twój post za bardzo pomocny. Do waszej gry ostatnio grałem w Vault i stwierdziłem, że nalegał on na IP.x 127.0.0.1 zamiast DNS.x 127 ... Nie sprawdziłem, czy jest to standard, czy nie.
Chomeh
4
Dziękuję @jww. Powiedziałeś: „1. Utwórz własny urząd (tj. Stań się urzędem certyfikacji)” , a następnie powiedz: „5. Zainstaluj certyfikat urzędu certyfikacji na kliencie” . Jeśli klucz root zostanie przejęty, złośliwa osoba może podpisać certyfikat dla dowolnej domeny za pomocą tego klucza, a jeśli nakłonią cię do przejścia na swoją stronę internetową, mogą teraz przeprowadzić atak typu man-in-the-middle. Czy istnieje sposób na utworzenie głównego urzędu certyfikacji w taki sposób, aby mógł podpisywać tylko pośrednie urzędy certyfikacji, a nie certyfikaty? Następnie możesz zabezpieczyć swój pośredni urząd certyfikacji za pomocą ograniczenia nazwy.
Robin Zimmermann
408

Oto opcje opisane w odpowiedzi @ diegows , opisane bardziej szczegółowo z dokumentacji :

openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days XXX
req

Żądanie certyfikatu PKCS # 10 i narzędzie do generowania certyfikatów.

-x509

ta opcja wyświetla certyfikat z podpisem własnym zamiast żądania certyfikatu. Jest to zwykle używane do generowania certyfikatu testowego lub samopodpisanego głównego urzędu certyfikacji.

-newkey arg

ta opcja tworzy nowe żądanie certyfikatu i nowy klucz prywatny. Argument przybiera jedną z kilku form. rsa: nbits , gdzie nbits jest liczbą bitów, generuje rozmiar klucza nbits RSA .

-keyout filename

daje to nazwę pliku do zapisania nowo utworzonego klucza prywatnego.

-out filename

Określa domyślną nazwę pliku wyjściowego do zapisu lub standardowe wyjście.

-days n

gdy używana jest opcja -x509, określa liczbę dni, dla których certyfikat będzie certyfikowany. Domyślnie jest to 30 dni.

-nodes

jeśli ta opcja jest określona, ​​to jeśli utworzony zostanie klucz prywatny, nie będzie on szyfrowany.

Dokumentacja jest w rzeczywistości bardziej szczegółowa niż powyższa; Właśnie to streściłem tutaj.

Peter Mortensen
źródło
3
W XXXpierwotnym poleceniu należy zastąpić „liczbą dni na poświadczenie certyfikatu”. Domyślnie jest to 30 dni. Na przykład -days XXXstaje się, -days 365jeśli chcesz, aby twój certyfikat był ważny przez 365 dni. Zobacz dokumentację, aby uzyskać więcej .
Nathan Jones,
Dziękujemy za dodanie dokumentacji. To łącze IBM dotyczące tworzenia samopodpisanego certyfikatu za pomocą polecenia, które wydaje się identyczne z odpowiedzią
The Red Pea
313

Od 2020 r. Następujące polecenie spełnia wszystkie Twoje potrzeby, w tym SAN:

openssl req -x509 -newkey rsa:4096 -sha256 -days 3650 -nodes \
  -keyout example.key -out example.crt -extensions san -config \
  <(echo "[req]"; 
    echo distinguished_name=req; 
    echo "[san]"; 
    echo subjectAltName=DNS:example.com,DNS:example.net,IP:10.0.0.1
    ) \
  -subj "/CN=example.com"

W OpenSSL ≥ 1.1.1 można to skrócić do:

openssl req -x509 -newkey rsa:4096 -sha256 -days 3650 -nodes \
  -keyout example.key -out example.crt -subj "/CN=example.com" \
  -addext "subjectAltName=DNS:example.com,DNS:example.net,IP:10.0.0.1"

Tworzy to certyfikat

  • ważne dla domen example.comi example.net(SAN),
  • ważne również dla adresu IP 10.0.0.1(SAN),
  • stosunkowo silny (od 2020 r.) oraz
  • ważne przez kilka 3650dni (~ 10 lat).

Tworzy następujące pliki:

  • Prywatny klucz: example.key
  • Certyfikat: example.crt

Wszystkie informacje są podawane w wierszu polecenia. Nie ma żadnych interaktywnych danych wejściowych, które Cię denerwują. Nie ma plików konfiguracyjnych, z którymi trzeba by się bawić. Wszystkie niezbędne kroki są wykonywane przez pojedyncze wywołanie OpenSSL : od wygenerowania klucza prywatnego do certyfikatu z podpisem własnym.

Uwaga 1: Parametry kryptograficzne

Ponieważ certyfikat jest samopodpisany i musi zostać ręcznie zaakceptowany przez użytkowników, nie ma sensu używać krótkiego terminu ważności lub słabej kryptografii.

W przyszłości możesz chcieć użyć więcej niż 4096bitów dla klucza RSA i algorytmu skrótu silniejszego niż sha256, ale od 2020 r. Są to rozsądne wartości. Są wystarczająco mocne, a jednocześnie obsługiwane przez wszystkie nowoczesne przeglądarki.

Uwaga 2: Parametr „ -nodes

Teoretycznie można pominąć -nodesparametr (co oznacza „brak szyfrowania DES”), w którym to przypadku example.keyzostanie zaszyfrowane hasłem. Jednak prawie nigdy nie jest to przydatne w przypadku instalacji serwera, ponieważ albo trzeba będzie zapisać hasło na serwerze, albo trzeba będzie wprowadzić je ręcznie przy każdym ponownym uruchomieniu.

Uwaga 3: Zobacz także

vog
źródło
1
Nie mogłem ustalić, co dokładnie należy winić w arg / CN = localhost rozwijającym się do C: / Program Files / Git / CN = localhost, więc po prostu uruchomiłem całe polecenie w zwykłym cmd.exe i zadziałało dobrze. Na wypadek, gdyby ktoś miał z tym problem.
Jurij Pozniak
1
@FranklinYu Czy jesteś pewien, że rsa: 2048 wystarczy za 10 lat? Ponieważ to jest okres ważności. Jak wyjaśniono, nie ma sensu używać krótkiego terminu ważności lub słabego szyfrowania. Większość 2048-bitowych kluczy RSA ma okres ważności najwyżej 1-3 lat. Jeśli chodzi o OpenSSL 1.1.1, nadal zostawiam tam sha256, więc zmiana jest bardziej wyraźna i oczywista, jeśli chcesz silniejszego skrótu.
vog
1
@DaveFerguson Czy certyfikat nie jest następnie tworzony //CN=localhostzamiast /CN=localhost? Czy właściwa ucieczka pomoże tutaj? Na przykład, czy zastąpienie /CN=localhostprzez "/CN=localhost"rozwiązuje problem w czysty sposób?
vog
4
1000 + 1s do utworzenia „jednowierszowego”, który korzysta z nowej wymaganej sieci SAN bez konieczności tworzenia długookresowego pliku konfiguracyjnego z dużą ilością płyty głównej. Dobra robota!
Joshua Pinter
1
@cautionbug Thanks! Właśnie edytowałem to w odpowiedzi. Czy odpowiedź jest teraz poprawna dla Windows / MinGW?
vog
142

Nie mogę komentować, dlatego umieszczę to jako osobną odpowiedź. Znalazłem kilka problemów z zaakceptowaną odpowiedzią jednoliniową:

  • Jednowarstwowy zawiera hasło w kluczu.
  • One-liner używa SHA-1, który w wielu przeglądarkach wyświetla ostrzeżenia w konsoli.

Oto uproszczona wersja, która usuwa hasło, podnosi bezpieczeństwo, aby ukryć ostrzeżenia i zawiera sugestię w komentarzach do przekazania w -subj, aby usunąć pełną listę pytań:

openssl genrsa -out server.key 2048
openssl rsa -in server.key -out server.key
openssl req -sha256 -new -key server.key -out server.csr -subj '/CN=localhost'
openssl x509 -req -sha256 -days 365 -in server.csr -signkey server.key -out server.crt

Zamień „localhost” na dowolną domenę, której potrzebujesz. Będziesz musiał uruchomić pierwsze dwa polecenia jeden po drugim, ponieważ OpenSSL poprosi o podanie hasła.

Aby połączyć oba w plik .pem:

cat server.crt server.key > cert.pem
Mike N.
źródło
6
Potrzebowałem certyfikatu dewelopera dla github.com/molnarg/node-http2 i ta odpowiedź jest po prostu najlepsza.
Capaj,
1
Aby połączyć certyfikat i klucz w jednym pliku: cat server.crt server.key >foo-cert.pem. Działa z przykładem wopenssl-1.0.2d/demos/ssl/
18446744073709551615
Certyfikat wygenerowany w ten sposób nadal używa SHA1.
user169771,
1
TKS, działa świetnie, aby utworzyć własny certyfikat podpisany na FreeBSD 10 OpenLDAP 2.4zTLS
Thiago Pereira
2
Co z plikiem key.pem?
quikchange
72

Nowoczesne przeglądarki zgłaszają teraz błąd bezpieczeństwa dla prawidłowo sformułowanych samopodpisanych certyfikatów, jeśli brakuje im SAN (alternatywna nazwa podmiotu). OpenSSL nie zapewnia wiersza polecenia do określenia tego , więc tutoriale i zakładki wielu programistów są nagle przestarzałe.

Najszybszym sposobem na ponowne uruchomienie jest krótki, samodzielny plik konf:

  1. Utwórz plik konfiguracyjny OpenSSL (Przykład: req.cnf)

    [req]
    distinguished_name = req_distinguished_name
    x509_extensions = v3_req
    prompt = no
    [req_distinguished_name]
    C = US
    ST = VA
    L = SomeCity
    O = MyCompany
    OU = MyDivision
    CN = www.company.com
    [v3_req]
    keyUsage = critical, digitalSignature, keyAgreement
    extendedKeyUsage = serverAuth
    subjectAltName = @alt_names
    [alt_names]
    DNS.1 = www.company.com
    DNS.2 = company.com
    DNS.3 = company.net
    
  2. Utwórz certyfikat odwołujący się do tego pliku konfiguracyjnego

    openssl req -x509 -nodes -days 730 -newkey rsa:2048 \
     -keyout cert.key -out cert.pem -config req.cnf -sha256
    

Przykładowa konfiguracja z https://support.citrix.com/article/CTX135602

rymo
źródło
1
Działa to dla mnie po usunięciu ostatniego parametru - rozszerzenia „v3_req”, który powodował błąd. Korzystanie z OpenSSL dla Windows. Wreszcie udało mi się rozwiązać ten problem! Dzięki.
CGodo
1
@ Kyopaxa masz rację - ten parametr jest zbędny w wierszu 3 pliku cnf; zaktualizowane.
rymo
2
Solidny sposób. Dzięki. Sugeruję dodanie -sha256.
cherouvim
5
Możesz teraz określić SAN w wierszu poleceń, -extension 'subjectAltName = DNS:dom.ain, DNS:oth.er'patrz github.com/openssl/openssl/pull/4986
Alexandre DuBreuil
2
Wygląda na to, że ta opcja jest -addextteraz wywoływana .
Alexandr Zarubkin
67

Polecam dodanie parametru -sha256 , aby użyć algorytmu skrótu SHA-2, ponieważ główne przeglądarki rozważają wyświetlanie „certyfikatów SHA-1” jako niezabezpieczonych.

Ta sama linia poleceń z zaakceptowanej odpowiedzi - @diegows z dodanym -sha256

openssl req -x509 -sha256 -newkey rsa: 2048 -keyout key.pem -out cert.pem-dni XXX

Więcej informacji na blogu Google Security .

Aktualizacja maja 2018 r. Jak wielu zauważyło w komentarzach, że używanie SHA-2 nie dodaje żadnych zabezpieczeń do certyfikatu z podpisem własnym. Ale nadal zalecam używanie go jako dobrego nawyku nieużywania przestarzałych / niepewnych kryptograficznych funkcji skrótu. Pełne wyjaśnienie jest dostępne w części Dlaczego w przypadku certyfikatów powyżej certyfikatu podmiotu końcowego oparcie SHA-1 jest w porządku? .

Maris B.
źródło
1
Jeśli jest to samopodpisany klucz, i tak generuje błędy przeglądarki, więc to nie ma znaczenia
Mark
30
@ Mark, ma to znaczenie, ponieważ SHA-2 jest bezpieczniejszy
Maris B.,
1
Otwarcie certyfikatu w systemie Windows po zmianie nazwy pliku cert.pem na cert.cer mówi, że algorytmem linii papilarnych jest nadal Sha1, ale algorytmem mieszania podpisu jest sha256.
zgrzeszyło
2
„Światowe szyfrowanie * zerowe uwierzytelnianie = zerowe bezpieczeństwo” gerv.net/security/self-signed-certs
x-yuri
4
Zauważ, że algorytm podpisu użyty w certyfikacie z podpisem własnym nie ma znaczenia przy podejmowaniu decyzji, czy jest wiarygodny, czy nie. Certyfikaty głównego urzędu certyfikacji są samopodpisane. a od maja 2018 r. nadal istnieje wiele aktywnych certyfikatów głównego urzędu certyfikacji, które są podpisane SHA-1. Ponieważ nie ma znaczenia, czy certyfikat ufa samemu sobie, ani w jaki sposób ten certyfikat weryfikuje to zaufanie. Albo ufasz rootowi / samopodpisanemu certyfikatowi, dla kogo on to mówi, albo nie. Zobacz security.stackexchange.com/questions/91913/…
Andrew Henle
20

To jest skrypt, którego używam w lokalnych skrzynkach, aby ustawić SAN (subjectAltName) w samopodpisanych certyfikatach.

Ten skrypt pobiera nazwę domeny (przyklad.com) i generuje sieć SAN dla * .example.com i przyklad.com w tym samym certyfikacie. Poniższe sekcje zostały skomentowane. Nazwij skrypt (np. generate-ssl.sh) I nadaj mu uprawnienia do wykonywania. Pliki zostaną zapisane w tym samym katalogu co skrypt.

Chrome 58 i nowsze wymagają ustawienia SAN w certyfikatach z podpisem własnym.

#!/usr/bin/env bash

# Set the TLD domain we want to use
BASE_DOMAIN="example.com"

# Days for the cert to live
DAYS=1095

# A blank passphrase
PASSPHRASE=""

# Generated configuration file
CONFIG_FILE="config.txt"

cat > $CONFIG_FILE <<-EOF
[req]
default_bits = 2048
prompt = no
default_md = sha256
x509_extensions = v3_req
distinguished_name = dn

[dn]
C = CA
ST = BC
L = Vancouver
O = Example Corp
OU = Testing Domain
emailAddress = webmaster@$BASE_DOMAIN
CN = $BASE_DOMAIN

[v3_req]
subjectAltName = @alt_names

[alt_names]
DNS.1 = *.$BASE_DOMAIN
DNS.2 = $BASE_DOMAIN
EOF

# The file name can be anything
FILE_NAME="$BASE_DOMAIN"

# Remove previous keys
echo "Removing existing certs like $FILE_NAME.*"
chmod 770 $FILE_NAME.*
rm $FILE_NAME.*

echo "Generating certs for $BASE_DOMAIN"

# Generate our Private Key, CSR and Certificate
# Use SHA-2 as SHA-1 is unsupported from Jan 1, 2017

openssl req -new -x509 -newkey rsa:2048 -sha256 -nodes -keyout "$FILE_NAME.key" -days $DAYS -out "$FILE_NAME.crt" -passin pass:$PASSPHRASE -config "$CONFIG_FILE"

# OPTIONAL - write an info to see the details of the generated crt
openssl x509 -noout -fingerprint -text < "$FILE_NAME.crt" > "$FILE_NAME.info"

# Protect the key
chmod 400 "$FILE_NAME.key"

Ten skrypt zapisuje również plik informacyjny, dzięki czemu można sprawdzić nowy certyfikat i sprawdzić, czy SAN jest prawidłowo ustawiony.

                ...
                28:dd:b8:1e:34:b5:b1:44:1a:60:6d:e3:3c:5a:c4:
                da:3d
            Exponent: 65537 (0x10001)
    X509v3 extensions:
        X509v3 Subject Alternative Name: 
            DNS:*.example.com, DNS:example.com
Signature Algorithm: sha256WithRSAEncryption
     3b:35:5a:d6:9e:92:4f:fc:f4:f4:87:78:cd:c7:8d:cd:8c:cc:
     ...

Jeśli używasz Apache, możesz odwołać się do powyższego certyfikatu w pliku konfiguracyjnym w następujący sposób:

<VirtualHost _default_:443>
    ServerName example.com
    ServerAlias www.example.com
    DocumentRoot /var/www/htdocs

    SSLEngine on
    SSLCertificateFile path/to/your/example.com.crt
    SSLCertificateKeyFile path/to/your/example.com.key
</VirtualHost>

Pamiętaj, aby ponownie uruchomić serwer Apache (lub Nginx lub IIS), aby nowy certyfikat zaczął obowiązywać.

Drakes
źródło
Działa na macOS High Siera i Chrome 58
Saqib Omer
Nadal nie jestem pewien, jak CN wpływa na ogólną konfigurację? Próbuję uruchomić to jako localhostlub 127.0.0.1:port#coś, co byłoby odpowiednie CNdla czegoś takiego.
DJ2
@ DJ2 Ustawiłbym BASE_DOMAIN = „localhost”
Drakes
9

One-liner 2017:

openssl req \
-newkey rsa:2048 \
-x509 \
-nodes \
-keyout server.pem \
-new \
-out server.pem \
-subj /CN=localhost \
-reqexts SAN \
-extensions SAN \
-config <(cat /System/Library/OpenSSL/openssl.cnf \
    <(printf '[SAN]\nsubjectAltName=DNS:localhost')) \
-sha256 \
-days 3650

Działa to również w Chrome 57, ponieważ zapewnia SAN, bez konieczności posiadania innego pliku konfiguracyjnego. Został zaczerpnięty z odpowiedzi tutaj .

Spowoduje to utworzenie pojedynczego pliku .pem zawierającego zarówno klucz prywatny, jak i certyfikat. W razie potrzeby możesz przenieść je do oddzielnych plików .pem.

joemillervi
źródło
2
Użytkownicy systemu Linux muszą zmienić tę ścieżkę konfiguracji. np. w sprawie bieżących /etc/ssl/openssl.confprac Ubuntu
deklinacja
Dla jednego-liner, który nie wymaga, aby określić lokalizację openssl.cnf patrz: stackoverflow.com/a/41366949/19163
VOG
7

Nie mogę komentować, więc dodam osobną odpowiedź. Próbowałem utworzyć samopodpisany certyfikat dla NGINX i było to łatwe, ale kiedy chciałem dodać go do białej listy Chrome, miałem problem. A moim rozwiązaniem było utworzenie certyfikatu głównego i podpisanie przez niego certyfikatu podrzędnego.

Więc krok po kroku. Utwórz plik config_ssl_ca.cnf Uwaga, plik konfiguracyjny ma opcję basicConstraints = CA: true, co oznacza, że ​​ten certyfikat ma być rootem.

Jest to dobra praktyka, ponieważ tworzysz ją raz i możesz użyć ponownie.

[ req ]
default_bits = 2048

prompt = no
distinguished_name=req_distinguished_name
req_extensions = v3_req

[ req_distinguished_name ]
countryName=UA
stateOrProvinceName=root region
localityName=root city
organizationName=root organisation
organizationalUnitName=roote department
commonName=root
[email protected]

[ alternate_names ]
DNS.1        = market.localhost
DNS.2        = www.market.localhost
DNS.3        = mail.market.localhost
DNS.4        = ftp.market.localhost

[ v3_req ]
keyUsage=digitalSignature
basicConstraints=CA:true
subjectKeyIdentifier = hash
subjectAltName = @alternate_names

Następny plik konfiguracyjny dla certyfikatu podrzędnego.

[ req ]
default_bits = 2048

prompt = no
distinguished_name=req_distinguished_name
req_extensions = v3_req

[ req_distinguished_name ]
countryName=UA
stateOrProvinceName=Kyiv region
localityName=Kyiv
organizationName=market place
organizationalUnitName=market place department
commonName=FirstName LastName
[email protected]

[ alternate_names ]
DNS.1        = market.localhost
DNS.2        = www.market.localhost
DNS.3        = mail.market.localhost
DNS.4        = ftp.market.localhost

[ v3_req ]
keyUsage=digitalSignature
basicConstraints=CA:false
subjectAltName = @alternate_names
subjectKeyIdentifier = hash

Pierwszy krok - utwórz klucz główny i certyfikat

openssl genrsa -out ca.key 2048
openssl req -new -x509 -key ca.key -out ca.crt -days 365 -config config_ssl_ca.cnf

Drugi krok tworzy klucz podrzędny i plik CSR - Żądanie podpisania certyfikatu. Ponieważ chodzi o podpisanie certyfikatu podrzędnego przez root i uzyskanie poprawnego certyfikatu

openssl genrsa -out market.key 2048
openssl req -new -sha256 -key market.key -config config_ssl.cnf -out market.csr

Otwórz terminal Linux i wykonaj to polecenie echo 0

echo 1 > ca.srl
touch index.txt

Ca.srl plik tekstowy zawierający kolejny numer seryjny, aby korzystać w hex. Obowiązkowy. Ten plik musi być obecny i zawierać prawidłowy numer seryjny.

Ostatni krok, stwórz jeszcze jeden plik konfiguracyjny i nazwij go config_ca.cnf

# we use 'ca' as the default section because we're usign the ca command
[ ca ]
default_ca = my_ca

[ my_ca ]
#  a text file containing the next serial number to use in hex. Mandatory.
#  This file must be present and contain a valid serial number.
serial = ./ca.srl

# the text database file to use. Mandatory. This file must be present though
# initially it will be empty.
database = ./index.txt

# specifies the directory where new certificates will be placed. Mandatory.
new_certs_dir = ./

# the file containing the CA certificate. Mandatory
certificate = ./ca.crt

# the file contaning the CA private key. Mandatory
private_key = ./ca.key

# the message digest algorithm. Remember to not use MD5
default_md = sha256

# for how many days will the signed certificate be valid
default_days = 365

# a section with a set of variables corresponding to DN fields
policy = my_policy

# MOST IMPORTANT PART OF THIS CONFIG
copy_extensions = copy

[ my_policy ]
# if the value is "match" then the field value must match the same field in the
# CA certificate. If the value is "supplied" then it must be present.
# Optional means it may be present. Any fields not mentioned are silently
# deleted.
countryName = match
stateOrProvinceName = supplied
organizationName = supplied
commonName = supplied
organizationalUnitName = optional
commonName = supplied

Możesz zapytać, dlaczego tak trudne, dlaczego musimy utworzyć jeszcze jedną konfigurację do podpisywania certyfikatu podrzędnego przez root. Odpowiedź jest prosta, ponieważ certyfikat podrzędny musi mieć blok SAN - alternatywne nazwy podmiotu. Jeśli podpiszemy certyfikat podrzędny za pomocą narzędzi „openssl x509”, certyfikat główny usunie pole SAN w certyfikacie podrzędnym. Dlatego używamy „openssl ca” zamiast „openssl x509”, aby uniknąć usunięcia pola SAN. Tworzymy nowy plik konfiguracyjny i każemy mu skopiować wszystkie rozszerzone pola copy_extensions = copy .

openssl ca -config config_ca.cnf -out market.crt -in market.csr

Program zadaje 2 pytania: 1. Podpisać certyfikat? Powiedz „T” 2. 1 z 1 certyfikatów jest poświadczonych, zatwierdzasz? Powiedz „Y”

W terminalu widać zdanie ze słowem „Baza danych”, oznacza to plik index.txt, który tworzysz za pomocą polecenia „dotknij”. Będzie zawierał wszystkie informacje według wszystkich certyfikatów utworzonych przez użytkownika „openssl ca”. Aby sprawdzić poprawność certyfikatu, użyj:

openssl rsa -in market.key -check

Jeśli chcesz zobaczyć, co jest w CRT:

openssl x509 -in market.crt -text -noout

Jeśli chcesz zobaczyć, co jest w CSR:

openssl req -in market.csr -noout -text 
mrkiril
źródło
2
Chociaż ten proces wygląda na skomplikowany, właśnie tego potrzebujemy dla domeny .dev, ponieważ ta domena nie obsługuje certyfikatów z podpisem własnym, a Chrome i Firefox wymuszają HSTS. Wykonałem następujące kroki, czyli tworzenie urzędu certyfikacji, tworzenie certyfikatu i podpisywanie go za pomocą mojego urzędu certyfikacji, a na koniec zaufanie do mojego urzędu certyfikacji w przeglądarce. Dzięki.
bajicdusko
1
Panie, jesteś cholerną legendą. Mój homelab dziękuje ci!
antsyawn
6

Poprawna jest ogólna procedura. Składnia polecenia jest poniżej.

openssl req -new -key {private key file} -out {output file}

Ostrzeżenia są jednak wyświetlane, ponieważ przeglądarka nie była w stanie zweryfikować tożsamości poprzez sprawdzenie certyfikatu za pomocą znanego ośrodka certyfikacji (CA).

Ponieważ jest to certyfikat z podpisem własnym, nie ma urzędu certyfikacji i można bezpiecznie zignorować ostrzeżenie i kontynuować. Jeśli chcesz uzyskać prawdziwy certyfikat, który będzie rozpoznawany przez kogokolwiek w publicznym Internecie, procedura jest poniżej.

  1. Wygeneruj klucz prywatny
  2. Użyj tego klucza prywatnego, aby utworzyć plik CSR
  3. Prześlij CSR do urzędu certyfikacji (Verisign lub inne itp.)
  4. Zainstaluj otrzymany certyfikat z urzędu certyfikacji na serwerze WWW
  5. Dodaj inne certyfikaty do łańcucha uwierzytelniania w zależności od typu certyfikatu

Mam więcej szczegółów na ten temat w poście w Securing the Connection: Creating the Security Certificate with OpenSSL

nneko
źródło
6

Jedna wkładka FTW. Lubię to prostsze. Dlaczego nie użyć jednego polecenia zawierającego WSZYSTKIE potrzebne argumenty? Tak mi się podoba - to tworzy certyfikat x509 i jego klucz PEM:

openssl req -x509 \
 -nodes -days 365 -newkey rsa:4096 \
 -keyout self.key.pem \
 -out self-x509.crt \
 -subj "/C=US/ST=WA/L=Seattle/CN=example.com/[email protected]"

To pojedyncze polecenie zawiera wszystkie odpowiedzi, które normalnie podajesz dla szczegółów certyfikatu. W ten sposób możesz ustawić parametry i uruchomić polecenie, uzyskać wynik - a potem iść na kawę.

>> Więcej tutaj <<

OkezieE
źródło
1
Wszystkie argumenty oprócz SAN ... @ vog również to obejmuje (i poprzedza to) (To wypełnia jednak pełniejsze pole „Temat” ...) (Nie jest też wielkim fanem rocznego wygaśnięcia)
Gert van den Berg,
6

Wersja jednoliniowa 2017:

CentOS:

openssl req -x509 -nodes -sha256 -newkey rsa:2048 \
-keyout localhost.key -out localhost.crt \
-days 3650 \
-subj "CN=localhost" \
-reqexts SAN -extensions SAN \
-config <(cat /etc/pki/tls/openssl.cnf <(printf "\n[SAN]\nsubjectAltName=IP:127.0.0.1,DNS:localhost"))

Ubuntu:

openssl req -x509 -nodes -sha256 -newkey rsa:2048 \
-keyout localhost.key -out localhost.crt \
-days 3650 \
-subj "/CN=localhost" \
-reqexts SAN -extensions SAN \
-config <(cat /etc/ssl/openssl.cnf <(printf "\n[SAN]\nsubjectAltName=IP:127.0.0.1,DNS:localhost"))

Edycja: dodano wcześniejszy Slash do opcji „subj” dla Ubuntu.

użytkownik327843
źródło
3

Generuj klucze

Używam /etc/mysqldo przechowywania certyfikatów, ponieważ /etc/apparmor.d/usr.sbin.mysqldzawiera /etc/mysql/*.pem r.

sudo su -
cd /etc/mysql
openssl genrsa -out ca-key.pem 2048;
openssl req -new -x509 -nodes -days 1000 -key ca-key.pem -out ca-cert.pem;
openssl req -newkey rsa:2048 -days 1000 -nodes -keyout server-key.pem -out server-req.pem;
openssl x509 -req -in server-req.pem -days 1000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 -out server-cert.pem;
openssl req -newkey rsa:2048 -days 1000 -nodes -keyout client-key.pem -out client-req.pem;
openssl x509 -req -in client-req.pem -days 1000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 -out client-cert.pem;

Dodaj konfigurację

/etc/mysql/my.cnf

[client]
ssl-ca=/etc/mysql/ca-cert.pem
ssl-cert=/etc/mysql/client-cert.pem
ssl-key=/etc/mysql/client-key.pem

[mysqld]
ssl-ca=/etc/mysql/ca-cert.pem
ssl-cert=/etc/mysql/server-cert.pem
ssl-key=/etc/mysql/server-key.pem

Podczas mojej instalacji serwer Ubuntu zalogował się do: /var/log/mysql/error.log

Dalsze uwagi:

  • SSL error: Unable to get certificate from '...'

    MySQL może zostać pozbawiony dostępu do odczytu pliku certyfikatu, jeśli nie jest on skonfigurowany przez Apparmors . Jak wspomniano w poprzednich krokach ^, zapisz wszystkie nasze certyfikaty jako .pempliki w /etc/mysql/katalogu, który jest domyślnie zatwierdzony przez apparmor (lub zmodyfikuj swojego apparmor / SELinux, aby umożliwić dostęp do każdego miejsca, w którym je zapisałeś).

  • SSL error: Unable to get private key

    Twoja wersja serwera MySQL może nie obsługiwać rsa:2048formatu domyślnego

    Konwertuj wygenerowany rsa:2048na zwykły za rsapomocą:

    openssl rsa -in server-key.pem -out server-key.pem
    openssl rsa -in client-key.pem -out client-key.pem
    
  • Sprawdź, czy lokalny serwer obsługuje SSL :

    mysql -u root -p
    mysql> show variables like "%ssl%";
    +---------------+----------------------------+
    | Variable_name | Value                      |
    +---------------+----------------------------+
    | have_openssl  | YES                        |
    | have_ssl      | YES                        |
    | ssl_ca        | /etc/mysql/ca-cert.pem     |
    | ssl_capath    |                            |
    | ssl_cert      | /etc/mysql/server-cert.pem |
    | ssl_cipher    |                            |
    | ssl_key       | /etc/mysql/server-key.pem  |
    +---------------+----------------------------+
    
  • Weryfikacja połączenia z bazą danych jest szyfrowana SSL :

    Weryfikacja połączenia

    Po zalogowaniu się do instancji MySQL możesz wysłać zapytanie:

    show status like 'Ssl_cipher';
    

    Jeśli twoje połączenie nie jest szyfrowane, wynik będzie pusty:

    mysql> show status like 'Ssl_cipher';
    +---------------+-------+
    | Variable_name | Value |
    +---------------+-------+
    | Ssl_cipher    |       |
    +---------------+-------+
    1 row in set (0.00 sec)
    

    W przeciwnym razie pokazałby ciąg znaków o niezerowej długości dla używanego szyfru:

    mysql> show status like 'Ssl_cipher';
    +---------------+--------------------+
    | Variable_name | Value              |
    +---------------+--------------------+
    | Ssl_cipher    | DHE-RSA-AES256-SHA |
    +---------------+--------------------+
    1 row in set (0.00 sec)
    
  • Wymagaj ssl dla konkretnego połączenia użytkownika („wymagaj ssl”):

    • SSL

    Informuje serwer, aby zezwalał tylko na połączenia szyfrowane SSL dla konta.

    GRANT ALL PRIVILEGES ON test.* TO 'root'@'localhost'
      REQUIRE SSL;
    

    Aby się połączyć, klient musi określić opcję --ssl-ca w celu uwierzytelnienia certyfikatu serwera, a dodatkowo może określić opcje --ssl-key i --ssl-cert. Jeśli nie podano ani opcji --ssl-ca, ani opcji --ssl-capath, klient nie uwierzytelnia certyfikatu serwera.


Alternatywny link: długi samouczek dotyczący bezpiecznych połączeń PHP z MySQL za pomocą protokołu SSL .

ThorSummoner
źródło
-1; jest to w dużej mierze styczne do zadanego pytania, a także źle wyjaśnia, skąd pochodzą jego cytaty.
Mark Amery
Pokazuje to obsługę certyfikatów CA, serwera / klienta podpisanych przez urząd certyfikacji, skonfigurowanie ich do odczytu przez mysqld na hoście z apparmor. Jest to przykład raczej bezużytecznego przypadku hostowania ca, serwera i klienta na tej samej maszynie i niebezpiecznie narażania uprawnień tego ca na proces mysqld. Ta konfiguracja nie ma sensu innego niż testowanie konfiguracji ssl w środowisku testowym. Do obsługi wewnętrznego urzędu certyfikacji poleciłbym zestaw narzędzi gnuttls zamiast openssl help.ubuntu.com/community/GnuTLS i dobrą znajomość tls przed obejściem sprawy mysqld + apparmor
ThorSummoner 29.09.19
3

Jak szczegółowo omówiono, certyfikaty z podpisem własnym nie są zaufane w Internecie . Możesz dodać samopodpisany certyfikat do wielu, ale nie wszystkich przeglądarek . Alternatywnie możesz zostać własnym urzędem certyfikacji .

Głównym powodem, dla którego nie chce się uzyskać podpisanego certyfikatu od urzędu certyfikacji, jest koszt - Symantec pobiera od 995 do 1 999 USD rocznie za certyfikaty - tylko za certyfikat przeznaczony dla sieci wewnętrznej, Symantec pobiera 399 USD rocznie . Koszt ten można łatwo uzasadnić, jeśli przetwarzasz płatności kartą kredytową lub pracujesz w centrum zysków bardzo dochodowej firmy. To więcej, niż wielu może sobie pozwolić na osobisty projekt, który tworzy się w Internecie, na non-profit działający przy minimalnym budżecie lub jeśli pracujesz w centrum kosztów organizacji - centra kosztów zawsze starają się robić więcej z mniej.

Alternatywą jest użycie certbota (zobacz o certbocie ). Certbot to łatwy w obsłudze automatyczny klient, który pobiera i wdraża certyfikaty SSL / TLS dla twojego serwera WWW.

Jeśli skonfigurujesz certbota, możesz umożliwić mu tworzenie i utrzymywanie certyfikatu wystawionego przez urząd certyfikacji Let's Encrypt .

Zrobiłem to w weekend dla mojej organizacji. Zainstalowałem wymagane pakiety dla certbota na moim serwerze (Ubuntu 16.04), a następnie uruchomiłem polecenie niezbędne do skonfigurowania i włączenia certbota. Najprawdopodobniej potrzebna jest wtyczka DNS dla certbota - obecnie korzystamy z DigitalOcean, ale wkrótce możemy przejść na inną usługę.

Pamiętaj, że niektóre instrukcje nie były w pełni poprawne i zajęło Google trochę czasu, aby je rozgryźć. Za pierwszym razem zajęło mi to sporo czasu, ale teraz myślę, że mógłbym to zrobić w kilka minut.

W przypadku DigitalOcean jednym z obszarów, z którym zmagałem się, było poproszenie mnie o podanie ścieżki do pliku INI poświadczeń DigitalOcean. Skrypt odnosi się do strony Aplikacje i API oraz zakładki Tokeny / Klucz na tej stronie. Musisz mieć lub wygenerować osobisty token dostępu (odczyt i zapis) dla API DigitalOcean - jest to ciąg znaków szesnastkowych o długości 65 znaków. Łańcuch ten należy następnie umieścić w pliku na serwerze WWW, z którego uruchomiono program certbot. Ten plik może mieć komentarz jako pierwszy wiersz (komentarze zaczynają się od #). Druga linia to:

dns_digitalocean_token = 0000111122223333444455556666777788889999aaaabbbbccccddddeeeeffff

Kiedy już wymyśliłem, jak skonfigurować token odczytu i zapisu dla interfejsu API DigitalOcean, całkiem łatwo było użyć certbota do skonfigurowania certyfikatu wieloznacznego . Zauważ, że nie trzeba konfigurować certyfikatu wieloznacznego, zamiast tego można określić każdą domenę i subdomenę, do której ma się stosować certyfikat. To certyfikat wieloznaczny wymagał pliku INI referencji, który zawierał osobisty token dostępu od DigitalOcean.

Należy pamiętać, że certyfikaty klucza publicznego (znane również jako certyfikaty tożsamości lub certyfikaty SSL) wygasają i wymagają odnowienia. W związku z tym konieczne będzie odnawianie certyfikatu okresowo (ponownie). Dokumentacja certbota obejmuje odnawianie certyfikatów .

Moim planem jest napisanie skryptu, aby użyć komendy openssl, aby uzyskać datę ważności mojego certyfikatu i uruchomić odnowienie, gdy upłynie 30 dni lub mniej, aż do wygaśnięcia. Dodam ten skrypt do crona i uruchamiam go raz dziennie.

Oto polecenie odczytu daty wygaśnięcia certyfikatu:

root@prod-host:~# /usr/bin/openssl x509 -enddate -noout -in path-to-certificate-pem-file
notAfter=May 25 19:24:12 2019 GMT
Peter Jirak Eldritch
źródło