Saya menambahkan dukungan HTTPS ke perangkat Linux tertanam. Saya telah mencoba membuat sertifikat yang ditandatangani sendiri dengan langkah-langkah ini:

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

Ini berfungsi, tetapi saya mendapatkan beberapa kesalahan dengan, misalnya, Google Chrome:

Ini mungkin bukan situs yang Anda cari!
Sertifikat keamanan situs tidak tepercaya!

Apakah saya melewatkan sesuatu? Apakah ini cara yang benar untuk membangun sertifikat yang ditandatangani sendiri?

Anda dapat melakukannya dalam satu perintah:

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

Anda juga dapat menambahkan -nodes(kependekan no DES) jika Anda tidak ingin melindungi kunci pribadi Anda dengan frasa sandi. Kalau tidak, akan diminta kata sandi "setidaknya 4 karakter".

The daysparameter (365) Anda dapat mengganti dengan nomor apapun untuk mempengaruhi tanggal kedaluwarsa. Ini kemudian akan meminta Anda untuk hal-hal seperti "Nama Negara", tetapi Anda bisa menekan Enterdan menerima default.

Tambahkan -subj '/CN=localhost'untuk menekan pertanyaan tentang konten sertifikat (ganti localhostdengan domain yang Anda inginkan).

Sertifikat yang ditandatangani sendiri tidak divalidasi dengan pihak ketiga mana pun kecuali Anda mengimpornya sebelumnya ke browser. Jika Anda membutuhkan keamanan lebih, Anda harus menggunakan sertifikat yang ditandatangani oleh otoritas sertifikat (CA).

Apakah saya melewatkan sesuatu? Apakah ini cara yang benar untuk membangun sertifikat yang ditandatangani sendiri?

Sangat mudah untuk membuat sertifikat yang ditandatangani sendiri. Anda cukup menggunakan openssl reqperintah. Mungkin sulit untuk membuatnya yang bisa dikonsumsi oleh pilihan klien terbesar, seperti browser dan alat baris perintah.

Ini sulit karena browser memiliki set persyaratan sendiri, dan mereka lebih ketat daripada IETF . Persyaratan yang digunakan oleh browser didokumentasikan di CA / Browser Forum (lihat referensi di bawah). Pembatasan muncul dalam dua bidang utama: (1) jangkar kepercayaan, dan (2) nama DNS.

Peramban modern (seperti warez yang kami gunakan pada 2014/2015) menginginkan sertifikat yang menghubungkan kembali ke jangkar kepercayaan, dan mereka ingin nama DNS disajikan dengan cara tertentu dalam sertifikat. Dan browser secara aktif bergerak melawan sertifikat server yang ditandatangani sendiri.

Beberapa browser tidak benar-benar membuatnya mudah untuk mengimpor sertifikat server yang ditandatangani sendiri. Faktanya, Anda tidak dapat menggunakan beberapa peramban, seperti peramban Android. Jadi solusi lengkapnya adalah menjadi otoritas Anda sendiri.

Dengan tidak adanya otoritas Anda sendiri, Anda harus mendapatkan hak nama DNS untuk memberikan sertifikat peluang sukses terbesar. Tetapi saya akan mendorong Anda untuk menjadi otoritas Anda sendiri. Sangat mudah untuk menjadi otoritas Anda sendiri, dan itu akan menghindari semua masalah kepercayaan (siapa yang lebih baik untuk dipercaya daripada diri Anda sendiri?).

Ini mungkin bukan situs yang Anda cari!
Sertifikat keamanan situs tidak tepercaya!

Ini karena browser menggunakan daftar jangkar trust yang telah ditentukan untuk memvalidasi sertifikat server. Sertifikat yang ditandatangani sendiri tidak mengikat kembali ke jangkar tepercaya.

Cara terbaik untuk menghindari ini adalah:

1. Buat otoritas Anda sendiri (yaitu, menjadi CA )
2. Buat permintaan penandatanganan sertifikat (CSR) untuk server
3. Tandatangani CSR server dengan kunci CA Anda
4. Instal sertifikat server di server
5. Instal sertifikat CA pada klien

Langkah 1 - Buat otoritas Anda sendiri hanya berarti membuat sertifikat yang ditandatangani sendiri dengan CA: truedan penggunaan kunci yang tepat. Itu berarti Subjek dan Penerbit adalah entitas yang sama, CA disetel ke true dalam Kendala Dasar (itu juga harus ditandai sebagai kritis), penggunaan kunci adalah keyCertSigndan crlSign(jika Anda menggunakan CRL), dan Subjek Key Identifier (SKI) adalah sama dengan Pengidentifikasi Kunci Otoritas (AKI).

Untuk menjadi otoritas sertifikat Anda sendiri, lihat * Bagaimana Anda menandatangani permintaan penandatanganan sertifikat dengan otoritas sertifikasi Anda? pada Stack Overflow. Kemudian, impor CA Anda ke Trust Store yang digunakan oleh browser.

Langkah 2 - 4 kira-kira apa yang Anda lakukan sekarang untuk server yang menghadap publik ketika Anda mendaftar layanan CA seperti Startcom atau CAcert . Langkah 1 dan 5 memungkinkan Anda untuk menghindari otoritas pihak ketiga, dan bertindak sebagai otoritas Anda sendiri (siapa yang lebih bisa dipercaya daripada diri Anda sendiri?).

Cara terbaik berikutnya untuk menghindari peringatan browser adalah dengan mempercayai sertifikat server. Tetapi beberapa browser, seperti browser default Android, jangan biarkan Anda melakukannya. Jadi itu tidak akan bekerja pada platform.

Masalah browser (dan agen pengguna serupa lainnya) tidak mempercayai sertifikat yang ditandatangani sendiri akan menjadi masalah besar di Internet of Things (IoT). Misalnya, apa yang akan terjadi ketika Anda terhubung ke termostat atau kulkas untuk memprogramnya? Jawabannya adalah, tidak ada yang baik sejauh pengalaman pengguna yang bersangkutan.

Kelompok Kerja WebAppSec W3C mulai melihat masalah ini. Lihat, misalnya, Proposal: Menandai HTTP Sebagai Tidak Aman .

Cara membuat sertifikat yang ditandatangani sendiri dengan OpenSSL

Perintah di bawah ini dan file konfigurasi membuat sertifikat yang ditandatangani sendiri (ini juga menunjukkan kepada Anda cara membuat permintaan penandatanganan). Mereka berbeda dari jawaban lain dalam satu hal: nama DNS yang digunakan untuk sertifikat yang ditandatangani sendiri adalah dalam Nama Alternatif Subjek (SAN) , dan bukan Nama Umum (CN) .

Nama DNS ditempatkan di SAN melalui file konfigurasi dengan baris subjectAltName = @alternate_names(tidak ada cara untuk melakukannya melalui baris perintah). Lalu ada alternate_namesbagian dalam file konfigurasi (Anda harus menyetel ini sesuai dengan selera Anda):

[ 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

Penting untuk menempatkan nama DNS di SAN dan bukan CN, karena baik IETF dan CA / Browser Forum menentukan praktiknya. Mereka juga menentukan bahwa nama-nama DNS di CN sudah usang (tetapi tidak dilarang). Jika Anda memasukkan nama DNS di CN, maka itu harus dimasukkan dalam SAN di bawah kebijakan CA / B. Jadi, Anda tidak dapat menghindari menggunakan Nama Alternatif Subjek.

Jika Anda tidak memasukkan nama DNS di SAN, maka sertifikat akan gagal divalidasi di bawah browser dan agen pengguna lain yang mengikuti pedoman CA / Browser Forum.

Terkait: browser mengikuti kebijakan CA / Browser Forum; dan bukan kebijakan IETF. Itulah salah satu alasan sertifikat yang dibuat dengan OpenSSL (yang umumnya mengikuti IETF) kadang-kadang tidak divalidasi di bawah browser (browser mengikuti CA / B). Mereka adalah standar yang berbeda, mereka memiliki kebijakan penerbitan yang berbeda dan persyaratan validasi yang berbeda.

Buat sertifikat yang ditandatangani sendiri (perhatikan penambahan -x509opsi):

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

Buat permintaan penandatanganan (perhatikan kurangnya -x509pilihan):

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

Cetak sertifikat yang ditandatangani sendiri :

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

Cetak permintaan penandatanganan :

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

File konfigurasi (diteruskan melalui -configopsi)

[ 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

Anda mungkin perlu melakukan yang berikut untuk Chrome. Kalau tidak, Chrome mungkin mengeluh Nama Biasa tidak valid ( ERR_CERT_COMMON_NAME_INVALID) . Saya tidak yakin apa hubungan antara alamat IP di SAN dan CN dalam hal ini.

# IPv4 localhost
# IP.1       = 127.0.0.1

# IPv6 localhost
# IP.2     = ::1

Ada aturan lain tentang penanganan nama DNS di sertifikat X.509 / PKIX. Lihat dokumen ini untuk aturan:

• RFC 5280, Internet X.509 Publik Infrastruktur Kunci Sertifikat dan Profil Daftar Pencabutan Sertifikat (CRL)
• RFC 6125, Representasi dan Verifikasi Identitas Layanan Aplikasi Berbasis Domain dalam Infrastruktur Kunci Publik Internet Menggunakan Sertifikat X.509 (PKIX) dalam Konteks Transport Layer Security (TLS)
• RFC 6797, Lampiran A, Keamanan Transportasi Ketat HTTP (HSTS)
• RFC 7469, Ekstensi Pinning Kunci Publik untuk HTTP
• Persyaratan Dasar CA / Browser Forum
• Pedoman Validasi Diperpanjang CA / Browser Forum

RFC 6797 dan RFC 7469 terdaftar, karena mereka lebih membatasi daripada RFC lain dan dokumen CA / B. RFC 6797 dan 7469 juga tidak mengizinkan alamat IP.

Berikut adalah opsi yang dijelaskan dalam jawaban @ diegows , dijelaskan secara lebih rinci, dari dokumentasi :

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

req

Permintaan sertifikat PKCS # 10 dan utilitas penghasil sertifikat.

-x509

opsi ini menampilkan sertifikat yang ditandatangani sendiri alih-alih permintaan sertifikat. Ini biasanya digunakan untuk menghasilkan sertifikat uji atau CA root yang ditandatangani sendiri.

-newkey arg

opsi ini membuat permintaan sertifikat baru dan kunci pribadi baru. Argumennya mengambil salah satu dari beberapa bentuk. rsa: nbits , di mana nbits adalah jumlah bit, menghasilkan nbits kunci RSA dalam ukuran.

-keyout filename

ini memberikan nama file untuk menulis kunci pribadi yang baru dibuat.

-out filename

Ini menentukan nama file output untuk menulis atau output standar secara default.

-days n

ketika opsi -x509 digunakan, ini menentukan jumlah hari untuk mengesahkan sertifikat. Standarnya adalah 30 hari.

-nodes

jika opsi ini ditentukan maka jika kunci pribadi dibuat tidak akan dienkripsi.

Dokumentasi sebenarnya lebih rinci daripada yang di atas; Saya baru saja merangkumnya di sini.

Pada 2020, perintah berikut melayani semua kebutuhan Anda, termasuk 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"

Dalam OpenSSL ≥ 1.1.1, ini dapat disingkat menjadi:

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"

Itu menciptakan sertifikat

• berlaku untuk domain example.comdan example.net(SAN),
• juga berlaku untuk alamat IP 10.0.0.1(SAN),
• relatif kuat (pada 2020) dan
• berlaku untuk 3650hari (~ 10 tahun).

Itu menciptakan file-file berikut:

• Kunci pribadi: example.key
• Sertifikat: example.crt

Semua informasi disediakan di baris perintah. Tidak ada input interaktif yang mengganggu Anda. Tidak ada file konfigurasi yang harus Anda mainkan. Semua langkah yang diperlukan dijalankan oleh satu permintaan OpenSSL : dari pembuatan kunci pribadi hingga sertifikat yang ditandatangani sendiri.

Komentar # 1: Parameter Crypto

Karena sertifikat ditandatangani sendiri dan perlu diterima oleh pengguna secara manual, tidak masuk akal untuk menggunakan kedaluwarsa singkat atau kriptografi yang lemah.

Di masa depan, Anda mungkin ingin menggunakan lebih dari 4096bit untuk kunci RSA dan algoritma hash yang lebih kuat daripada sha256, tetapi pada tahun 2020 ini adalah nilai yang waras. Mereka cukup kuat saat didukung oleh semua browser modern.

Komentar # 2: Parameter " -nodes"

Secara teoritis Anda dapat meninggalkan -nodesparameter (yang berarti "tidak ada enkripsi DES"), dalam hal ini example.keyakan dienkripsi dengan kata sandi. Namun, ini hampir tidak pernah berguna untuk instalasi server, karena Anda harus menyimpan kata sandi di server juga, atau Anda harus memasukkannya secara manual pada setiap reboot.

Komentar # 3: Lihat juga

• Berikan subjectAltName ke openssl langsung pada baris perintah
• Bagaimana cara menambahkan beberapa alamat email ke sertifikat SSL melalui baris perintah?
• Informasi lebih lanjut tentang MSYS_NO_PATHCONV

Saya tidak bisa berkomentar, jadi saya akan menempatkan ini sebagai jawaban terpisah. Saya menemukan beberapa masalah dengan jawaban satu baris yang diterima:

• One-liner menyertakan frasa sandi di kunci.
• One-liner menggunakan SHA-1 yang di banyak browser melemparkan peringatan di konsol.

Berikut ini adalah versi sederhana yang menghilangkan frasa sandi, meningkatkan keamanan untuk menekan peringatan dan memasukkan saran dalam komentar untuk lulus -subj untuk menghapus daftar pertanyaan lengkap:

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

Ganti 'localhost' dengan domain apa pun yang Anda butuhkan. Anda perlu menjalankan dua perintah pertama satu per satu karena OpenSSL akan meminta frasa sandi.

Untuk menggabungkan keduanya menjadi file .pem:

cat server.crt server.key > cert.pem

Browser modern sekarang membuat kesalahan keamanan untuk sertifikat yang ditandatangani sendiri jika tidak ada SAN (Nama Alternatif Subjek). OpenSSL tidak menyediakan cara baris perintah untuk menentukan ini , sehingga banyak tutorial dan bookmark pengembang yang tiba-tiba kedaluwarsa.

Cara tercepat untuk menjalankan kembali adalah file conf pendek, berdiri sendiri:

1. Buat file konfigurasi OpenSSL (contoh 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. Buat sertifikat referensi file konfigurasi ini

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

Contoh konfigurasi dari https://support.citrix.com/article/CTX135602

Saya akan merekomendasikan untuk menambahkan parameter -sha256 , untuk menggunakan algoritma hash SHA-2, karena browser utama sedang mempertimbangkan untuk menunjukkan "sertifikat SHA-1" sebagai tidak aman.

Baris perintah yang sama dari jawaban yang diterima - @diegows dengan menambahkan -sha256

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

Informasi lebih lanjut di blog Google Security .

Perbarui Mei 2018. Seperti yang banyak dicatat dalam komentar bahwa menggunakan SHA-2 tidak menambah keamanan pada sertifikat yang ditandatangani sendiri. Tapi saya masih merekomendasikan menggunakannya sebagai kebiasaan yang baik untuk tidak menggunakan fungsi hash kriptografi yang sudah usang / tidak aman. Penjelasan lengkap tersedia di Mengapa sertifikat di atas entitas akhir boleh saja berbasis SHA-1? .

Ini adalah skrip yang saya gunakan pada kotak lokal untuk mengatur SAN (subjectAltName) dalam sertifikat yang ditandatangani sendiri.

Skrip ini mengambil nama domain (example.com) dan menghasilkan SAN untuk * .example.com dan example.com dalam sertifikat yang sama. Bagian di bawah ini dikomentari. Beri nama skrip (mis. generate-ssl.sh) Dan berikan izin yang dapat dieksekusi. File akan ditulis ke direktori yang sama dengan skrip.

Chrome 58 dan selanjutnya mengharuskan SAN ditetapkan dalam sertifikat yang ditandatangani sendiri.

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

Skrip ini juga menulis file informasi, sehingga Anda dapat memeriksa sertifikat baru dan memverifikasi bahwa SAN telah diatur dengan benar.

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

Jika Anda menggunakan Apache, maka Anda dapat merujuk sertifikat di atas dalam file konfigurasi Anda seperti:

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

Ingatlah untuk memulai kembali server Apache (atau Nginx, atau IIS) Anda agar sertifikat baru berlaku.

2017 satu-liner:

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

Ini juga berfungsi di Chrome 57, karena menyediakan SAN, tanpa memiliki file konfigurasi lain. Itu diambil dari jawaban di sini .

Ini menciptakan file .pem tunggal yang berisi kunci pribadi dan cert. Anda dapat memindahkannya untuk memisahkan file .pem jika diperlukan.

Saya tidak bisa berkomentar jadi saya menambahkan jawaban yang terpisah. Saya mencoba membuat sertifikat yang ditandatangani sendiri untuk NGINX dan itu mudah, tetapi ketika saya ingin menambahkannya ke daftar putih Chrome, saya punya masalah. Dan solusi saya adalah membuat sertifikat Root dan menandatangani sertifikat anak.

Jadi selangkah demi selangkah. Buat file config_ssl_ca.cnf Perhatikan, file config memiliki opsi basicConstraints = CA: true yang berarti bahwa sertifikat ini seharusnya menjadi root.

Ini adalah praktik yang baik, karena Anda membuatnya sekali dan dapat digunakan kembali.

[ 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

File konfigurasi berikutnya untuk sertifikat anak Anda.

[ 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

Langkah pertama - buat kunci Root dan sertifikat

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

Langkah kedua membuat kunci anak dan mengajukan CSR - Permintaan Penandatanganan Sertifikat. Karena idenya adalah untuk menandatangani sertifikat anak dengan root dan mendapatkan sertifikat yang benar

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

Buka terminal Linux dan lakukan perintah ini echo 0

echo 1 > ca.srl
touch index.txt

The ca.srl file teks yang berisi nomor seri berikutnya untuk digunakan dalam hex. Wajib. File ini harus ada dan berisi nomor seri yang valid.

Langkah Terakhir, buat satu file konfigurasi lagi dan beri nama 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

Anda mungkin bertanya, mengapa sangat sulit, mengapa kita harus membuat satu konfigurasi lagi untuk menandatangani sertifikat anak oleh root. Jawabannya sederhana karena sertifikat anak harus memiliki blok SAN - Nama Alternatif Subjek. Jika kami menandatangani sertifikat anak dengan utils "openssl x509", sertifikat Root akan menghapus bidang SAN dalam sertifikat anak. Jadi kami menggunakan "openssl ca" bukannya "openssl x509" untuk menghindari penghapusan bidang SAN. Kami membuat file konfigurasi baru dan menyuruhnya untuk menyalin semua bidang yang diperluas copy_extensions = salin .

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

Program ini menanyakan 2 pertanyaan kepada Anda: 1. Menandatangani sertifikat? Katakan "Y" 2. 1 dari 1 permintaan sertifikat disertifikasi, komit? Katakan "Y"

Di terminal Anda dapat melihat kalimat dengan kata "Database", itu berarti file index.txt yang Anda buat dengan perintah "touch". Ini akan berisi semua informasi dengan semua sertifikat yang Anda buat dengan util "openssl ca". Untuk memeriksa sertifikat, gunakan valid:

openssl rsa -in market.key -check

Jika Anda ingin melihat isinya di dalam CRT:

openssl x509 -in market.crt -text -noout

Jika Anda ingin melihat bagian dalam CSR:

openssl req -in market.csr -noout -text 

Anda memiliki prosedur umum yang benar. Sintaks untuk perintah di bawah ini.

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

Namun, peringatan ditampilkan, karena browser tidak dapat memverifikasi identifikasi dengan memvalidasi sertifikat dengan Otoritas Sertifikat (CA) yang dikenal.

Karena ini adalah sertifikat yang ditandatangani sendiri, tidak ada CA dan Anda dapat dengan aman mengabaikan peringatan itu dan melanjutkan. Jika Anda ingin mendapatkan sertifikat nyata yang akan dikenali oleh siapa pun di Internet publik maka prosedurnya di bawah ini.

1. Buat kunci pribadi
2. Gunakan kunci pribadi itu untuk membuat file CSR
3. Kirim CSR ke CA (Verisign atau yang lain, dll.)
4. Instal sertifikat yang diterima dari CA di server web
5. Tambahkan sertifikat lain ke rantai otentikasi tergantung pada jenis sertifikat

Saya memiliki rincian lebih lanjut tentang ini di posting di Mengamankan Koneksi: Membuat Sertifikat Keamanan dengan OpenSSL

Satu liner FTW. Saya suka membuatnya sederhana. Mengapa tidak menggunakan satu perintah yang berisi SEMUA argumen yang dibutuhkan? Inilah yang saya suka - ini membuat sertifikat x509 dan kunci PEM-nya:

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"

Perintah tunggal itu berisi semua jawaban yang biasanya Anda berikan untuk perincian sertifikat. Dengan cara ini Anda dapat mengatur parameter dan menjalankan perintah, dapatkan output Anda - lalu pergi untuk minum kopi.

>> Lebih lanjut di sini <<

Versi satu liner 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"))

Sunting: menambahkan opsi Slash ke 'subj' yang ditambahkan untuk Ubuntu.

Buat kunci

Saya menggunakan /etc/mysqluntuk penyimpanan cert karena /etc/apparmor.d/usr.sbin.mysqldmengandung /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;

Tambahkan konfigurasi

/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

Pada pengaturan saya, server Ubuntu login ke: /var/log/mysql/error.log

Catatan tindak lanjut:

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

  MySQL mungkin ditolak akses baca ke file sertifikat Anda jika tidak dalam konfigurasi aparatur . Seperti disebutkan dalam langkah sebelumnya ^, simpan semua sertifikat kami sebagai .pemfile di /etc/mysql/direktori yang disetujui secara default oleh apparmor (atau modifikasi apparmor / SELinux Anda untuk memungkinkan akses ke mana pun Anda menyimpannya.)

• SSL error: Unable to get private key

  Versi server MySQL Anda mungkin tidak mendukung rsa:2048format default

  Konversi yang dihasilkan rsa:2048ke polos rsadengan:

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

• Periksa apakah server lokal mendukung 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  |
  +---------------+----------------------------+
  

• Memverifikasi koneksi ke database terenkripsi SSL :

  Memverifikasi koneksi

  Saat masuk ke instance MySQL, Anda dapat mengeluarkan kueri:

  show status like 'Ssl_cipher';
  

  Jika koneksi Anda tidak dienkripsi, hasilnya akan kosong:

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

  Jika tidak, itu akan menampilkan string panjang non-nol untuk sandi yang digunakan:

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

• Membutuhkan ssl untuk koneksi pengguna tertentu ('memerlukan ssl'):

  • SSL

  Memberitahu server untuk mengizinkan hanya koneksi terenkripsi SSL untuk akun.

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

  Untuk menghubungkan, klien harus menentukan opsi --ssl-ca untuk mengotentikasi sertifikat server, dan juga dapat menentukan opsi --ssl-key dan --ssl-cert. Jika opsi --ssl-ca atau opsi --ssl-capath tidak ditentukan, klien tidak mengotentikasi sertifikat server.

Tautan alternatif: Tutorial yang panjang dalam Koneksi PHP Aman ke MySQL dengan SSL .

Seperti telah dibahas secara rinci, sertifikat yang ditandatangani sendiri tidak dipercaya untuk Internet . Anda dapat menambahkan sertifikat yang Anda tandatangani sendiri ke banyak tetapi tidak semua browser . Atau Anda dapat menjadi otoritas sertifikat Anda sendiri .

Alasan utama seseorang tidak ingin mendapatkan sertifikat yang ditandatangani dari otoritas sertifikat adalah biaya - biaya Symantec antara $ 995 - $ 1.999 per tahun untuk sertifikat - hanya untuk sertifikat yang ditujukan untuk jaringan internal, Symantec mengenakan biaya $ 399 per tahun . Biaya itu mudah untuk dibenarkan jika Anda memproses pembayaran kartu kredit atau bekerja untuk pusat laba perusahaan yang sangat menguntungkan. Ini lebih dari yang mampu dimiliki oleh proyek pribadi yang dibuat di internet, atau untuk nirlaba yang berjalan dengan anggaran minimal, atau jika seseorang bekerja di pusat biaya organisasi - pusat biaya selalu berusaha melakukan lebih banyak dengan kurang.

Alternatifnya adalah menggunakan certbot (lihat tentang certbot ). Certbot adalah klien otomatis yang mudah digunakan yang mengambil dan menyebarkan sertifikat SSL / TLS untuk server web Anda.

Jika Anda mengatur certbot, Anda dapat mengaktifkannya untuk membuat dan mengelola sertifikat untuk Anda yang dikeluarkan oleh otoritas sertifikat Let's Encrypt .

Saya melakukan ini selama akhir pekan untuk organisasi saya. Saya menginstal paket yang diperlukan untuk certbot di server saya (Ubuntu 16.04) dan kemudian menjalankan perintah yang diperlukan untuk mengatur dan mengaktifkan certbot. Satu kemungkinan membutuhkan plugin DNS untuk certbot - kami saat ini menggunakan DigitalOcean meskipun mungkin akan bermigrasi ke layanan lain segera.

Perhatikan bahwa beberapa petunjuknya kurang tepat dan perlu sedikit waktu untuk mencari tahu. Ini mengambil cukup banyak waktu saya pertama kali, tetapi sekarang saya pikir saya bisa melakukannya dalam beberapa menit.

Untuk DigitalOcean, satu area yang saya perjuangkan adalah ketika saya diminta untuk memasukkan jalur ke file INI kredensial DigitalOcean Anda. Yang dimaksud skrip adalah halaman Aplikasi & API dan tab Token / Kunci pada halaman itu. Anda perlu memiliki atau membuat token akses pribadi (baca dan tulis) untuk DigitalOcean's API - ini adalah string heksadesimal 65 karakter. String ini kemudian perlu dimasukkan ke dalam file di server web tempat Anda menjalankan certbot. File itu dapat memiliki komentar sebagai baris pertama (komentar dimulai dengan #). Garis kedua adalah:

dns_digitalocean_token = 0000111122223333444455556666777788889999aaaabbbbccccddddeeeeffff

Setelah saya menemukan cara mengatur token baca + tulis untuk API DigitalOcean, cukup mudah untuk menggunakan certbot untuk mengatur sertifikat wildcard . Perhatikan bahwa seseorang tidak harus mensetup sertifikat wildcard, seseorang dapat menentukan masing-masing domain dan sub-domain yang ingin disertifikasi oleh sertifikat tersebut. Itu adalah sertifikat wildcard yang memerlukan file INI kredensial yang berisi token akses pribadi dari DigitalOcean.

Perhatikan bahwa sertifikat kunci publik (juga dikenal sebagai sertifikat identitas atau sertifikat SSL) kedaluwarsa dan memerlukan pembaruan. Dengan demikian, Anda perlu memperbarui sertifikat Anda secara berkala (berulang). Dokumentasi certbot mencakup perpanjangan sertifikat .

Rencana saya adalah menulis sebuah skrip untuk menggunakan perintah openssl untuk mendapatkan tanggal kedaluwarsa sertifikat saya dan untuk memicu pembaruan ketika 30 hari atau kurang sampai berakhir. Saya kemudian akan menambahkan skrip ini ke cron dan menjalankannya sekali per hari.

Ini adalah perintah untuk membaca tanggal kedaluwarsa sertifikat Anda:

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