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?

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).

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        = test@example.com

# 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 5280, Internet X.509 Certyfikat infrastruktury klucza publicznego i profil listy odwołania certyfikatów (CRL)
• RFC 6125, Reprezentacja i weryfikacja tożsamości usługi aplikacji opartej na domenie w infrastrukturze Internetu klucza publicznego za pomocą certyfikatów X.509 (PKIX) w kontekście zabezpieczeń warstwy transportowej (TLS)
• RFC 6797, dodatek A, HTTP Strict Transport Security (HSTS)
• RFC 7469, Rozszerzenie przypinania klucza publicznego dla HTTP
• Wymagania dotyczące forum CA / Browser Forum
• Wytyczne dotyczące rozszerzonej walidacji forum CA / przeglądarki

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.

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.

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

• Podaj subjectAltName do openssl bezpośrednio w wierszu poleceń
• Jak dodać wiele adresów e-mail do certyfikatu SSL za pomocą wiersza polecenia?
• Więcej informacji o MSYS_NO_PATHCONV

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

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

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? .

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ć.

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.

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
emailAddress=root_email@root.localhost

[ 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
emailAddress=email@market.localhost

[ 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 

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

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/emailAddress=someEmail@gmail.com"

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 <<

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.

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 .

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