Gömülü bir Linux aygıtına HTTPS desteği ekliyorum. Şu adımlarla kendinden imzalı bir sertifika oluşturmaya çalıştım:

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

Bu işe yarıyor, ancak örneğin Google Chrome ile ilgili bazı hatalar alıyorum:

Bu muhtemelen aradığınız site değil!
Bu sitenin güvenlik sertifikası güvenilir değil!

Bir şey mi kaçırıyorum? Bu kendinden imzalı bir sertifika oluşturmanın doğru yolu mu?

Bunu tek bir komutta yapabilirsiniz:

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

Özel anahtarınızı bir parola ile korumak istemiyorsanız da -nodes(kısaltması no DES) ekleyebilirsiniz . Aksi takdirde sizden "en az 4 karakterli" bir şifre isteyecektir.

Son dayskullanma tarihini etkilemek için herhangi bir sayı ile değiştirebileceğiniz parametre (365). Daha sonra "Ülke Adı" gibi şeyler isteyecektir, ancak Entervarsayılanları tıklayıp kabul edebilirsiniz .

-subj '/CN=localhost'Sertifikanın içeriği hakkındaki soruları bastırmak için ekleyin ( localhostistediğiniz alan adıyla değiştirin ).

Kendinden imzalı sertifikalar, daha önce tarayıcılara aktarmadığınız sürece herhangi bir üçüncü tarafla doğrulanmaz. Daha fazla güvenliğe ihtiyacınız varsa, bir sertifika yetkilisi (CA) tarafından imzalanmış bir sertifika kullanmalısınız .

Bir şey mi kaçırıyorum? Bu kendinden imzalı bir sertifika oluşturmanın doğru yolu mu?

Kendinden imzalı bir sertifika oluşturmak kolaydır. Sadece openssl reqkomutu kullanın. Tarayıcılar ve komut satırı araçları gibi en geniş istemciler tarafından tüketilebilecek bir tane oluşturmak zor olabilir.

Bu zor çünkü tarayıcıların kendi gereksinimleri var ve IETF'den daha kısıtlayıcılar . Tarayıcılar tarafından kullanılan gereksinimler CA / Tarayıcı Forumlarında belgelenmiştir (aşağıdaki referanslara bakın). Kısıtlamalar iki kilit alanda ortaya çıkar: (1) güven bağlantıları ve (2) DNS adları.

Modern tarayıcılar (2014/2015'te kullandığımız warez gibi) güven bağlantısına zincirlenen bir sertifika ister ve DNS adlarının sertifikada belirli şekillerde sunulmasını ister. Ve tarayıcılar aktif olarak kendinden imzalı sunucu sertifikalarına karşı hareket ediyor.

Bazı tarayıcılar, kendinden imzalı bir sunucu sertifikası almayı tam olarak kolaylaştırmaz. Aslında, Android'in tarayıcısı gibi bazı tarayıcılarla yapamazsınız. Yani tam çözüm kendi otoriteniz olmaktır.

Kendi otoriteniz olmadığında, sertifikaya en büyük başarı şansını vermek için DNS adlarını doğru almanız gerekir. Ama sizi kendi otoriteniz olmaya teşvik ediyorum. Kendi otoriteniz olmak kolaydır ve tüm güven sorunlarını ortadan kaldıracaktır (kendinizden daha iyi kim güvenebilir?).

Bu muhtemelen aradığınız site değil!
Bu sitenin güvenlik sertifikası güvenilir değil!

Bunun nedeni, tarayıcıların sunucu sertifikalarını doğrulamak için önceden tanımlanmış bir güven bağlantısı listesi kullanmasıdır. Kendinden imzalı bir sertifika güvenilir bir bağlantıya geri zincirlenmez.

Bundan kaçınmanın en iyi yolu:

1. Kendi otoritenizi oluşturun (yani bir CA olun )
2. Sunucu için sertifika imzalama isteği (CSR) oluşturma
3. Sunucunuzun CSR'sini CA anahtarınızla imzalayın
4. Sunucu sertifikasını sunucuya yükleyin
5. CA sertifikasını istemciye yükleyin

Adım 1 - Kendi otoritenizi oluşturmak, yalnızca kendinden imzalı bir sertifika CA: trueve uygun anahtar kullanımı oluşturmak anlamına gelir . Bu, Konu ve Sertifikayı veren kuruluşun aynı varlık olduğu, Temel Kısıtlamalarda CA'nın true olarak ayarlandığı (ayrıca kritik olarak işaretlenmesi gerekir), anahtar kullanımının keyCertSignve crlSign(CRL kullanıyorsanız) ve Konu Anahtarı Tanımlayıcısının (SKI) Yetkili Anahtar Tanımlayıcısı (AKI) ile aynıdır .

Kendi sertifika yetkiliniz olmak için bkz. * Sertifika yetkilinizle nasıl bir sertifika imzalama isteği imzalarsınız? Overflow üzerinde. Ardından, CA'nızı tarayıcı tarafından kullanılan Güven Deposuna alın.

Adım 2 - 4, Startcom veya CAcert gibi bir CA'nın hizmetlerine kaydolduğunuzda , genel olarak karşı karşıya olan bir sunucu için kabaca yaptığınız adımlardır . Adım 1 ve 5, üçüncü taraf otoriteden kaçınmanıza ve kendi otoriteniz gibi davranmanıza izin verir (kendinizden daha iyi kim güvenebilir?).

Tarayıcı uyarısından kaçınmanın bir sonraki en iyi yolu sunucunun sertifikasına güvenmektir. Ancak, Android'in varsayılan tarayıcısı gibi bazı tarayıcılar bunu yapmanıza izin vermez. Yani platformda asla çalışmayacak.

Tarayıcılar (ve diğer benzer kullanıcı aracılarına) sorunu değil kendinden imzalı sertifikaları güvenen Things (IOT) İnternetinde büyük bir sorun olacak. Örneğin, programlamak için termostatınıza veya buzdolabınıza bağladığınızda ne olacak? Cevap, kullanıcı deneyimi açısından iyi bir şey değildir.

W3C'nin WebAppSec Çalışma Grubu bu konuya bakmaya başlıyor. Örneğin, Teklif: HTTP'yi Güvenli Olmayan Olarak İşaretleme konusuna bakın .

OpenSSL ile kendinden imzalı bir sertifika nasıl oluşturulur

Aşağıdaki komutlar ve yapılandırma dosyası kendinden imzalı bir sertifika oluşturur (ayrıca imzalama isteğinin nasıl oluşturulacağını gösterir). Bir açıdan diğer cevaplardan farklıdırlar: Kendinden imzalı sertifika için kullanılan DNS adları Ortak Adı (CN) değil, Konu Alternatif Adı'nda (SAN ) bulunmaktadır .

DNS adları SAN'a satırlı yapılandırma dosyası aracılığıyla yerleştirilir subjectAltName = @alternate_names(komut satırından bunu yapmanın bir yolu yoktur). Sonra alternate_namesyapılandırma dosyasında bir bölüm var (bunu zevkinize göre ayarlamanız gerekir):

[ 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

DNS adını SAN'a değil CN'ye koymak önemlidir, çünkü hem IETF hem de CA / Tarayıcı Forumları uygulamayı belirtir. Ayrıca CN'deki DNS adlarının onaylanmadığını (ancak yasaklanmadığını) belirtirler. Eğer sen CN bir DNS adı koymak, o zaman gerekir CA / B politikaları altında SAN dahil edilmesi. Böylece Konu Alternatif Adını kullanmaktan kaçınamazsınız.

SAN'a DNS adları koymazsanız, sertifika bir tarayıcı ve CA / Tarayıcı Forumu yönergelerini izleyen diğer kullanıcı aracıları altında doğrulanamaz.

İlgili: tarayıcılar CA / Tarayıcı Forumu ilkelerini izler; ve IETF politikalarını değil. Bu, OpenSSL ile oluşturulan bir sertifikanın (genellikle IETF'yi izleyen) bazen bir tarayıcı altında doğrulanmamasının nedenlerinden biridir (tarayıcılar CA / B'yi takip eder). Farklı standartlardır, farklı ihraç politikaları ve farklı onaylama gereksinimleri vardır.

Kendinden imzalı bir sertifika oluşturun ( -x509seçeneğin eklenmesine dikkat edin ):

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

İmzalama isteği oluşturun ( -x509seçeneğin eksikliğine dikkat edin ):

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

Kendinden imzalı bir sertifika yazdırın :

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

İmzalama isteği yazdırın :

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

Yapılandırma dosyası ( -configseçenek üzerinden geçirilir )

[ 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

Chrome için aşağıdakileri yapmanız gerekebilir. Aksi takdirde Chrome, Ortak Adın geçersiz olduğundan şikayet edebilir ( ERR_CERT_COMMON_NAME_INVALID) . Bu örnekte SAN'daki bir IP adresi ile bir CN arasındaki ilişkinin ne olduğundan emin değilim.

# IPv4 localhost
# IP.1       = 127.0.0.1

# IPv6 localhost
# IP.2     = ::1

X.509 / PKIX sertifikalarında DNS adlarının işlenmesine ilişkin başka kurallar da vardır. Kurallar için bu belgelere bakın:

• RFC 5280, Internet X.509 Ortak Anahtar Altyapısı Sertifikası ve Sertifika İptal Listesi (CRL) Profili
• RFC 6125, Taşıma Katmanı Güvenliği (TLS) Bağlamında X.509 (PKIX) Sertifikaları Kullanılarak Internet Ortak Anahtar Altyapısı İçinde Etki Alanı Tabanlı Uygulama Hizmeti Kimliğinin Temsil Edilmesi ve Doğrulanması
• RFC 6797, Ek A, HTTP Sıkı Aktarım Güvenliği (HSTS)
• RFC 7469, HTTP için Ortak Anahtar Sabitleme Uzantısı
• CA / Tarayıcı Forumu Temel Gereksinimleri
• CA / Tarayıcı Forumu Genişletilmiş Doğrulama Yönergeleri

RFC 6797 ve RFC 7469 listelenmiştir, çünkü bunlar diğer RFC ve CA / B belgelerinden daha kısıtlayıcıdır. RFC 6797 ve 7469 da bir IP adresine izin vermez.

Burada anlatılan seçenekler diegows cevabı @ , daha ayrıntılı olarak açıklanan, dokümantasyon :

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

req

PKCS # 10 sertifika isteği ve sertifika oluşturma yardımcı programı.

-x509

bu seçenek, sertifika isteği yerine kendinden imzalı bir sertifika verir. Bu genellikle bir test sertifikası veya kendinden imzalı bir kök CA oluşturmak için kullanılır.

-newkey arg

bu seçenek yeni bir sertifika isteği ve yeni bir özel anahtar oluşturur. Argüman çeşitli biçimlerden birini alır. rsa: nbits , burada nbits bit sayısı, boyut olarak bir RSA anahtarı nbits üretir .

-keyout filename

bu, yeni oluşturulan özel anahtarı yazmak için dosya adını verir.

-out filename

Bu, varsayılan olarak yazılacak çıktı dosya adını veya standart çıktıyı belirtir.

-days n

ne zaman -x509 seçenek bu belirliyorsa kullanılıyor günlerin sayısı için sertifika tasdik. Varsayılan süre 30 gündür.

-nodes

bu seçenek belirtilirse özel anahtar oluşturulursa şifrelenmez.

Belgeler aslında yukarıdakilerden daha ayrıntılıdır; Sadece burada özetledim.

2020 itibariyle, aşağıdaki komut SAN dahil tüm ihtiyaçlarınızı karşılar:

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"

OpenSSL ≥ 1.1.1'de bu kısaltılabilir:

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"

Bu bir sertifika oluşturur

• etki alanları example.comve example.net(SAN) için geçerli ,
• IP adresi 10.0.0.1(SAN) için de geçerlidir ,
• nispeten güçlü (2020 itibariyle) ve
• 3650günler için geçerlidir (~ 10 yıl).

Aşağıdaki dosyaları oluşturur:

• Özel anahtar: example.key
• Sertifika: example.crt

Tüm bilgiler komut satırında sağlanır. Orada hiçbir interaktif giriş sizi rahatsız ediyor. Orada hiçbir ayar dosyaları sen etrafında karışıklık var. Gerekli tüm adımlar tek bir OpenSSL çağırma ile yürütülür : özel anahtar oluşturma işleminden otomatik olarak imzalanan sertifikaya kadar.

Açıklama 1: Kripto parametreleri

Sertifika kendinden imzalı olduğundan ve kullanıcılar tarafından manuel olarak kabul edilmesi gerektiğinden, kısa bir süre sonu veya zayıf şifreleme kullanmak mantıklı değildir.

Gelecekte, 4096RSA anahtarı ve daha güçlü bir karma algoritması için bitlerden daha fazlasını kullanmak isteyebilirsiniz sha256, ancak 2020'den itibaren bunlar aklı başında değerlerdir. Tüm modern tarayıcılar tarafından desteklenirken yeterince güçlüdürler.

Açıklama # 2: " -nodes" parametresi

Teorik olarak -nodesparametreyi ("DES şifrelemesi yok" anlamına gelir) dışarıda bırakabilirsiniz , bu durumda example.keybir şifre ile şifrelenir. Ancak, bu neredeyse hiçbir zaman sunucu kurulumu için yararlı değildir, çünkü parolayı sunucuda da saklamanız veya her yeniden başlatmada manuel olarak girmeniz gerekir.

Açıklama # 3: Ayrıca bakınız

• SubjectAltName öğesini doğrudan komut satırında openssl'e sağlama
• Komut satırı üzerinden bir SSL sertifikasına birden çok e-posta adresi nasıl eklenir?
• MSYS_NO_PATHCONV hakkında daha fazla bilgi

Yorum yapamam, bu yüzden bunu ayrı bir cevap olarak koyacağım. Kabul edilen tek satırlık cevapla ilgili birkaç sorun buldum:

• Tek astar anahtarda bir parola içerir.
• Tek astar, birçok tarayıcıda konsolda uyarı veren SHA-1 kullanır.

İşte parolayı kaldıran, uyarıları bastırmak için güvenliği artıran ve tüm soru listesini kaldırmak için -subj'a geçmek için yorumlarda bir öneri içeren basitleştirilmiş bir sürüm:

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

'Localhost'u istediğiniz alan adıyla değiştirin. OpenSSL bir parola isteyeceğinden, ilk iki komutu tek tek çalıştırmanız gerekecektir.

İkisini bir .pem dosyasında birleştirmek için:

cat server.crt server.key > cert.pem

Modern tarayıcılar artık SAN (Konu Alternatif Adı) eksikse, iyi biçimlendirilmiş kendinden imzalı sertifikalar için bir güvenlik hatası verir. OpenSSL bunu belirtmek için bir komut satırı yolu sağlamaz , bu nedenle birçok geliştiricinin öğreticileri ve yer işaretleri aniden eskimiş olur.

Tekrar çalıştırmanın en hızlı yolu kısa, bağımsız bir conf dosyasıdır:

1. (Örnek: Bir OpenSSL yapılandırma dosyası oluşturma 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. Bu yapılandırma dosyasına başvuran sertifikayı oluşturun

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

Https://support.citrix.com/article/CTX135602 adresinden örnek yapılandırma

Büyük tarayıcılar "SHA-1 sertifikalarını" güvenli değil olarak göstermeyi düşündüklerinden, SHA-2 karma algoritmasını kullanmak için -sha256 parametresini eklemenizi öneririm .

Kabul edilen cevaptaki aynı komut satırı - @diegows ve -sha256 eklendi

openssl req -x509 -sha256 -yeni anahtar rsa: 2048 -kayı anahtarı .pem -out cert.pem -günler XXX

Google Güvenlik blogunda daha fazla bilgi .

Mayıs 2018'de güncelleyin . Yorumlarda belirtildiği gibi, SHA-2 kullanmanın kendinden imzalı bir sertifikaya herhangi bir güvenlik eklemediği. Ama yine de eski / güvensiz kriptografik hash işlevlerini kullanmama gibi iyi bir alışkanlık olarak kullanmanızı öneririm. Tam açıklama, Nihai varlık sertifikasının üzerindeki sertifikaların SHA-1 tabanlı olması neden iyidir? .

Bu, kendinden imzalı sertifikalarda SAN (topicAltName) ayarlamak için yerel kutularda kullandığım komut dosyasıdır.

Bu komut dosyası etki alanı adını (example.com) alır ve aynı sertifikada * .example.com ve example.com için SAN oluşturur. Aşağıdaki bölümler yorumlanmıştır. Komut dosyasına ad generate-ssl.shverin (örn. ) Ve çalıştırılabilir izinler verin. Dosyalar komut dosyasıyla aynı dizine yazılır.

Chrome 58 ve yukarısı, SAN'ın kendinden imzalı sertifikalarda ayarlanmasını gerektirir.

#!/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"

Bu komut dosyası da bir bilgi dosyası yazar, böylece yeni sertifikayı inceleyebilir ve SAN'ın doğru ayarlandığını doğrulayabilirsiniz.

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

Apache kullanıyorsanız, yapılandırma dosyanızda yukarıdaki sertifikaya şu şekilde başvurabilirsiniz:

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

Yeni sertifikanın geçerli olması için Apache (veya Nginx veya IIS) sunucunuzu yeniden başlatmayı unutmayın.

2017 tek astarlı:

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

Bu, başka bir yapılandırma dosyası olmadan SAN'ı sağladığı için Chrome 57'de de çalışır. Bu bir cevap alındı burada .

Bu, hem özel anahtarı hem de sertifikayı içeren tek bir .pem dosyası oluşturur. Gerekirse bunları .pem dosyalarını ayırmak için taşıyabilirsiniz.

Yorum yapamam, bu yüzden ayrı bir cevap ekliyorum. NGINX için kendinden imzalı bir sertifika oluşturmaya çalıştım ve kolaydı, ancak Chrome beyaz listesine eklemek istediğimde bir sorun yaşadım. Ve benim çözümüm bir Kök sertifika oluşturmak ve onun tarafından bir alt sertifika imzalamaktı.

Yani adım adım. Dosya oluştur config_ssl_ca.cnf Dikkat, yapılandırma dosyası basicConstraints = CA: true seçeneğine sahiptir, bu da bu sertifikanın kök olması gerektiği anlamına gelir.

Bu iyi bir uygulamadır, çünkü bir kez yaratırsınız ve tekrar kullanabilirsiniz.

[ 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

Alt sertifikanız için bir sonraki yapılandırma dosyası.

[ 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

İlk adım - Kök anahtarı ve sertifika oluşturma

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

İkinci adım, alt anahtar ve dosya CSR - Sertifika İmzalama İsteği oluşturur. Çünkü fikir, alt sertifikayı kök ile imzalamak ve doğru bir sertifika almaktır

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

Linux terminalini açın ve echo 0 komutunu yapın

echo 1 > ca.srl
touch index.txt

Ca.srl sonraki seri numarasını içeren bir metin dosyası onaltılık kullanmak. Zorunlu. Bu dosya mevcut olmalı ve geçerli bir seri numarası içermelidir.

Son Adım, bir yapılandırma dosyası daha oluşturun ve onu config_ca.cnf olarak adlandırın

# 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

Neden bu kadar zor olduğunu, alt sertifikayı kökten imzalamak için neden bir yapılandırma daha oluşturmamız gerektiğini sorabilirsiniz. Alt sertifika, bir SAN bloğuna sahip olmalıdır - Konu Alternatif Adları. Alt sertifikayı "openssl x509" araçlarıyla imzalarsak, Kök sertifika alt sertifikadaki SAN alanını siler. Bu yüzden SAN alanının silinmesini önlemek için "openssl x509" yerine "openssl ca" kullanıyoruz. Yeni bir yapılandırma dosyası oluşturuyoruz ve ona tüm genişletilmiş alanları kopyalamasını söylüyoruz copy_extensions = copy .

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

Program size 2 soru soruyor: 1. Sertifikayı imzalansın mı? "Y" deyin. 1 sertifika talebinden 1'i onaylandı mı? "Y" de

Terminalde "Veritabanı" kelimesini içeren bir cümle görebilirsiniz, "dokunma" komutu ile oluşturduğunuz index.txt dosyası anlamına gelir. "Openssl ca" util tarafından oluşturduğunuz tüm sertifikaların tüm bilgilerini içerecektir. Sertifikanın geçerli kullanımını kontrol etmek için:

openssl rsa -in market.key -check

CRT'de içeride ne olduğunu görmek istiyorsanız:

openssl x509 -in market.crt -text -noout

KSS'de içeride ne olduğunu görmek istiyorsanız:

openssl req -in market.csr -noout -text 

Genel prosedür doğru. Komutun sözdizimi aşağıdadır.

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

Ancak, tarayıcı, sertifikayı bilinen bir Sertifika Yetkilisi (CA) ile sertifikayı doğrulayarak kimliği doğrulayamadığı için uyarılar görüntülenir.

Bu kendinden imzalı bir sertifika olduğundan CA yoktur ve uyarıyı göz ardı edebilir ve devam edebilirsiniz. Genel internetteki herkes tarafından tanınabilecek gerçek bir sertifika almak istiyorsanız, prosedür aşağıdadır.

1. Özel anahtar oluşturma
2. Bir CSR dosyası oluşturmak için bu özel anahtarı kullanın
3. CSR'yi CA'ya gönderme (Verisign veya diğerleri vb.)
4. Web sunucusuna CA'dan alınan sertifikayı yükleyin
5. Sertifika türüne bağlı olarak kimlik doğrulama zincirine başka sertifikalar ekleyin

Bu konuda daha fazla ayrıntı var Bağlantı Güvenliğini Sağlama: OpenSSL ile Güvenlik Sertifikası Oluşturma

Bir astar FTW. Basit tutmayı seviyorum. Neden TÜM bağımsız değişkenleri içeren bir komut kullanmıyorsunuz? Ben böyle seviyorum - bu bir x509 sertifikası ve PEM anahtarı oluşturur:

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"

Bu tek komut, normalde sertifika ayrıntıları için vereceğiniz tüm yanıtları içerir. Bu şekilde parametreleri ayarlayabilir ve komutu çalıştırabilir, çıktınızı alabilirsiniz - sonra kahve için gidin.

>> Buradan daha fazlası <<

Tek katmanlı versiyon 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"))

Düzenleme: Ubuntu için 'subj' seçeneğine eğik çizgi ekledi.

Anahtar üret

/etc/mysqlCert depolama için kullanıyorum çünkü /etc/apparmor.d/usr.sbin.mysqldiçerir /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;

Yapılandırma ekle

/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

Kurulumumda, Ubuntu sunucusu oturum açtı: /var/log/mysql/error.log

Takip notları:

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

  MySQL, apparmors yapılandırmasında değilse sertifika dosyanıza okuma erişimine izin verilmeyebilir . Önceki adımlarda ^ belirtildiği gibi, tüm sertifikalarımızı varsayılan olarak apparmor tarafından onaylanan dizine .pemdosyalar olarak /etc/mysql/kaydedin (veya depoladığınız yere erişime izin vermek için apparmor / SELinux'unuzu değiştirin.)

• SSL error: Unable to get private key

  MySQL sunucu sürümünüz varsayılanı desteklemeyebilir rsa:2048 formatı

  Şununla oluştur : rsa:2048düzleştir rsa:

  openssl rsa -in server-key.pem -out server-key.pem
  openssl rsa -in client-key.pem -out client-key.pem
  

• Yerel sunucunun SSL'yi destekleyip desteklemediğini kontrol edin :

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

• Veritabanına bir bağlantının SSL şifreli olduğunu doğrulamak :

  Bağlantıyı doğrulama

  MySQL örneğinde oturum açtığınızda, sorguyu yayınlayabilirsiniz:

  show status like 'Ssl_cipher';
  

  Bağlantınız şifrelenmezse sonuç boş olur:

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

  Aksi takdirde, kullanılan şifre için sıfır olmayan bir uzunluk dizesi gösterir:

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

• Belirli bir kullanıcının bağlantısı için SSL iste ('SSL gerektirir'):

  • SSL

  Sunucuya hesap için yalnızca SSL şifreli bağlantılara izin vermesini söyler.

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

  Bağlanmak için istemci, sunucu sertifikasının kimliğini doğrulamak için --ssl-ca seçeneğini belirtmeli ve ayrıca --ssl-key ve --ssl-cert seçeneklerini belirtebilir. --Ssl-ca seçeneği veya --ssl-capath seçeneği belirtilmezse, istemci sunucu sertifikasının kimliğini doğrulamaz.

Alternatif bağlantı: SSL ile MySQL'e Güvenli PHP Bağlantılarında uzun öğretici .

Ayrıntılı olarak tartışıldığı gibi, kendinden imzalı sertifikalar İnternet için güvenilir değildir . Sen olabilir birçok ancak tüm tarayıcılar için otomatik olarak imzalanan sertifika ekle . Alternatif olarak kendi sertifika yetkiliniz olabilirsiniz .

Bir kişinin bir sertifika yetkilisinden imzalı bir sertifika almak istememesinin başlıca nedeni maliyettir - Symantec sertifikalar için yılda 995 $ - 1.999 $ arasında ücret alır - sadece dahili ağ için tasarlanmış bir sertifika için Symantec yılda 399 $ talep eder . Kredi kartı ödemelerini işliyor veya yüksek kârlı bir şirketin kâr merkezi için çalışıyorsanız bu maliyetin haklı gösterilmesi kolaydır. Birinin internette oluşturduğu kişisel bir proje için ya da asgari bir bütçeyle çalışan kar amacı gütmeyen bir kişi için veya bir kuruluşun maliyet merkezinde çalışıyorsa - maliyet merkezleri her zaman daha fazlasını yapmaya çalışır. daha az.

Bir alternatif, certbot kullanmaktır ( certbot hakkında bilgi için ). Certbot, web sunucunuz için SSL / TLS sertifikalarını alan ve dağıtan, kullanımı kolay bir otomatik istemcidir.

Certbot'u kurarsanız, Let's Encrypt sertifika yetkilisi tarafından verilen bir sertifika oluşturup sürdürmesini sağlayabilirsiniz .

Bunu hafta sonu organizasyonum için yaptım. Certbot için gerekli paketleri sunucuma (Ubuntu 16.04) yükledim ve sonra certbot'u kurmak ve etkinleştirmek için gerekli komutu çalıştırdım. Muhtemelen certbot için bir DNS eklentisine ihtiyacı var - şu anda DigitalOcean kullanıyoruz, ancak yakında başka bir hizmete geçiyor olabiliriz.

Bazı talimatların tam olarak doğru olmadığını ve anlaması için Google'la biraz uğraştığını ve biraz zaman aldığını unutmayın. Bu benim ilk defa çok fazla zamanımı aldı ama şimdi sanırım dakikalar içinde yapabilirim.

DigitalOcean için, mücadele ettiğim bir alan, DigitalOcean kimlik bilgileri INI dosyanızın yolunu girmem istendi. Komut dosyasının belirttiği şey, Uygulamalar ve API sayfası ve o sayfadaki Jetonlar / Anahtar sekmesidir. DigitalOcean API'sı için kişisel bir erişim belirtecine (okuma ve yazma) sahip olmanız veya oluşturmanız gerekir - bu 65 karakterlik bir onaltılık dizedir. Bu dize daha sonra certbot çalıştırdığınız web sunucusunda bir dosyaya konulmalıdır. Bu dosyanın ilk satırı olarak bir yorumu olabilir (yorumlar # ile başlar). İkinci satır:

dns_digitalocean_token = 0000111122223333444455556666777788889999aaaabbbbccccddddeeeeffff

DigitalOcean API'sı için bir okuma + yazma belirtecinin nasıl ayarlanacağını anladıktan sonra, joker karakter sertifikası ayarlamak için certbot kullanmak oldukça kolaydı . Bir kişinin joker karakter sertifikası kurması gerekmediğini, bunun yerine sertifikanın uygulanmasını istediği her bir etki alanını ve alt etki alanını belirtebilirsiniz. DigitalOcean'dan kişisel erişim belirtecini içeren kimlik bilgileri INI dosyasını gerektiren joker karakter sertifikasıydı.

Ortak anahtar sertifikalarının (kimlik sertifikaları veya SSL sertifikaları olarak da bilinir) süresinin dolduğunu ve yenilenmesini gerektirdiğini unutmayın. Bu nedenle sertifikanızı periyodik olarak (tekrarlayan) yenilemeniz gerekir. Certbot belgeleri, sertifikaların yenilenmesini kapsar .

Planım, sertifikamın sona erme tarihini almak için openssl komutunu kullanmak ve süresi sona erene kadar 30 gün veya daha kısa bir sürede yenilemeyi tetiklemek için bir komut dosyası yazmak. Daha sonra bu betiği cron'a ekleyeceğim ve günde bir kez çalıştıracağım.

Sertifikanızın son kullanma tarihini okuma komutu şöyledir:

root@prod-host:~# /usr/bin/openssl x509 -enddate -noout -in path-to-certificate-pem-file
notAfter=May 25 19:24:12 2019 GMT