Cara membuat sertifikat yang ditandatangani sendiri dengan OpenSSL

1294

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?

michelemarcon
sumber
40
Sertifikat yang ditandatangani sendiri dianggap tidak aman untuk Internet. Firefox akan menganggap situs tersebut memiliki sertifikat yang tidak valid, sementara Chrome akan bertindak seolah-olah koneksi itu HTTP biasa. Lebih detail: gerv.net/security/self-signed-certs
user1202136
34
Anda perlu mengimpor sertifikat CA ke peramban dan memberi tahu peramban bahwa Anda mempercayai sertifikat itu - atau - membuatnya ditandatangani oleh salah satu organisasi besar yang tidak menghasilkan apa-apa yang sudah dipercaya oleh peramban - atau mengabaikan peringatan dan klik melewatinya. Saya suka opsi terakhir sendiri.
trojanfoe
12
Anda seharusnya tidak menggunakan pengaturan OpenSSL "stok" seperti itu. Itu karena Anda tidak dapat menempatkan nama DNS di Subject Alternate Name (SAN). Anda perlu menyediakan file konfigurasi dengan alternate_namesbagian dan memberikannya dengan -configopsi. Juga, menempatkan nama DNS di Common Name (CN) sudah usang (tetapi tidak dilarang) oleh IETF dan CA / Browser Forum. Setiap nama DNS di CN juga harus ada di SAN. Tidak ada cara untuk menghindari penggunaan SAN. Lihat jawaban di bawah ini.
jww
5
Selain komentar @jww. Per Mei 2017 Chrome tidak menerima sertifikat tanpa (SAN) lagi: "Sertifikat untuk situs ini tidak mengandung ekstensi Nama Alternatif Subjek yang berisi nama domain atau alamat IP."
GerardJP
6
Saat ini, selama server web Anda dapat diakses oleh FQDN-nya pada port 80 melalui internet, Anda dapat menggunakan LetsEncrypt dan mendapatkan sertifikat CA gratis penuh (berlaku selama 90 hari, pembaruan dapat otomatis) yang tidak akan memberikan peringatan browser / pesan. www.letsencrypt.com
Barny

Jawaban:

2131

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

Diego Woitasen
sumber
8
Bagi siapa saja yang tertarik, inilah dokumentasinya , jika Anda ingin memverifikasi sesuatu sendiri.
17
Bagaimana cara menandatangani dengan pihak ketiga memberikan keamanan lebih?
James Mills
201
Untuk siapa pun yang menggunakan ini dalam otomatisasi, berikut adalah semua parameter umum untuk subjek:-subj "/C=US/ST=Oregon/L=Portland/O=Company Name/OU=Org/CN=www.example.com"
Alex S
17
@JamesMills Maksudku, pikirkanlah - jika seorang pria yang tampak teduh dengan "permen gratis" yang tertulis di samping van-nya mengundang Anda untuk masuk, Anda benar-benar akan berpikir dua kali dan berjaga-jaga - tetapi Jika seseorang yang Anda percayai - seperti benar - benar percaya - semuanya seperti, "tidak, dia sah" Anda akan semua tentang permen gratis itu.
BrainSlugs83
73
Ingatlah untuk menggunakan -sha256untuk menghasilkan sertifikat berbasis SHA-256.
Gea-Suan Lin
536

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        = [email protected]

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

subjectKeyIdentifier        = hash
authorityKeyIdentifier    = keyid,issuer

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

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

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

subjectKeyIdentifier        = hash

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

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

[ alternate_names ]

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

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

# IPv6 localhost
# DNS.8     = ::1

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

jww
sumber
4
Apakah mungkin menggunakan wildcard di alternate_namesbagian ini? Khususnya sub-sub domain. Saya punya pertanyaan yang merujuk jawaban ini di sini: serverfault.com/questions/711596/…
LeonardChallis
3
Saya baru saja menjawab pertanyaan spesifiknya. Saya pikir tidak masuk akal untuk menambahkan deskripsi keamanan yang panjang ini ketika jawabannya sangat sederhana
Diego Woitasen
14
@diegows - jawaban Anda tidak lengkap atau benar. Alasannya tidak benar dibahas dalam posting panjang yang tidak ingin Anda baca :)
jww
1
Terima kasih! Saya menemukan posting Anda sangat membantu. FYI Saya baru-baru ini bermain dengan kubah dan menemukannya bersikeras pada IP.x 127.0.0.1 daripada DNS.x 127 ... Saya tidak memeriksa apakah ini dalam standar atau tidak.
Chomeh
4
@Jww terima kasih. Anda berkata, "1. Buat otoritas Anda sendiri (yaitu, menjadi CA)" , lalu berkata, "5. Instal sertifikat CA pada klien" . Jika kunci root dikompromikan, orang jahat dapat menandatangani sertifikat untuk domain apa pun dengan kunci itu, dan jika mereka menipu Anda untuk mengunjungi situs web mereka, mereka sekarang dapat melakukan serangan manusia-di-tengah. Apakah ada cara untuk membuat CA root sehingga hanya bisa menandatangani CA perantara dan bukan sertifikat? Kemudian Anda dapat melindungi CA perantara Anda dengan batasan nama.
Robin Zimmermann
408

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.

Peter Mortensen
sumber
3
The XXXdalam perintah asli harus diganti dengan 'jumlah hari untuk mengesahkan sertifikat untuk'. Standarnya adalah 30 hari. Misalnya, -days XXXmenjadi -days 365jika Anda ingin sertifikat Anda valid selama 365 hari. Lihat dokumen untuk lebih lanjut .
Nathan Jones
Terima kasih telah menambahkan dokumentasi. Tautan IBM ini tentang membuat sertifikat yang ditandatangani sendiri menggunakan perintah yang tampaknya identik dengan jawaban ini
The Red Pea
314

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

vog
sumber
1
Saya tidak tahu apa yang harus disalahkan dalam arg / CN = localhost yang meluas ke C: / Program Files / Git / CN = localhost, jadi saya hanya menjalankan seluruh perintah dalam cmd.exe biasa dan itu bekerja dengan baik. Kalau-kalau ada seseorang yang berjuang dengan yang ini.
Yuriy Pozniak
1
@ FranklinYu Apakah Anda yakin bahwa rsa: 2048 akan cukup dalam 10 tahun dari sekarang? Karena itulah masa berlaku. Seperti yang dijelaskan, tidak masuk akal untuk menggunakan kedaluwarsa pendek atau crypto lemah. Sebagian besar kunci RSA 2048-bit memiliki masa berlaku paling lama 1-3 tahun. Mengenai OpenSSL 1.1.1, saya masih meninggalkan sha256 di sana, jadi lebih eksplisit dan jelas untuk berubah jika Anda menginginkan hash yang lebih kuat.
vog
1
@DaveFerguson Bukankah sertifikat kemudian dibuat untuk //CN=localhostbukan /CN=localhost? Apakah melarikan diri yang tepat akan membantu di sini? Misalnya, apakah mengganti /CN=localhostdengan "/CN=localhost"menyelesaikan masalah dengan cara yang bersih?
vog
4
1000 +1 untuk membuat "satu-liner" yang menggunakan SAN baru yang diperlukan tanpa harus membuat file konfigurasi panjang lebar dengan banyak boilerplate. Sudah selesai dilakukan dengan baik!
Joshua Pinter
1
@cautionbug Terima kasih! Saya baru saja mengedit ini menjadi jawabannya. Apakah jawabannya sekarang benar untuk Windows / MinGW?
vog
143

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
Mike N
sumber
6
Saya membutuhkan sertifikat dev untuk github.com/molnarg/node-http2 dan jawaban ini adalah yang terbaik.
Capaj
1
Untuk menggabungkan sertifikat dan kunci dalam satu file: cat server.crt server.key >foo-cert.pem. Bekerja dengan contoh diopenssl-1.0.2d/demos/ssl/
18446744073709551615
Cert yang saya hasilkan dengan cara ini masih menggunakan SHA1.
user169771
1
Tks, bekerja hebat untuk membuat sertifikat yang ditandatangani sendiri FreeBSD 10 OpenLDAP 2.4denganTLS
Thiago Pereira
2
Bagaimana dengan file key.pem?
quikchange
72

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

rymo
sumber
1
Itu bekerja untuk saya setelah menghapus parameter terakhir-ekstensi 'v3_req' yang menyebabkan kesalahan. Menggunakan OpenSSL untuk windows. Akhirnya, saya berhasil memperbaiki masalah ini! Terima kasih.
CGodo
1
@Kyopaxa Anda benar - parameter itu berlebihan dengan baris 3 file cnf; diperbarui.
rymo
2
Cara yang solid. Terima kasih. Saya sarankan menambahkan -sha256.
cherouvim
5
Anda sekarang dapat menentukan SAN pada baris perintah dengan -extension 'subjectAltName = DNS:dom.ain, DNS:oth.er'melihat github.com/openssl/openssl/pull/4986
Alexandre DuBreuil
2
Sepertinya opsi ini dipanggil -addextsekarang.
Alexandr Zarubkin
67

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

Maris B.
sumber
1
Jika itu adalah kunci yang ditandatangani sendiri, ini akan menghasilkan kesalahan peramban, jadi ini tidak terlalu penting
Tandai
30
@ Mark, itu penting, karena SHA-2 lebih aman
Maris B.
1
Membuka sertifikat di windows setelah mengganti nama cert.pem ke cert.cer mengatakan algoritma sidik jari masih Sha1, tetapi algoritma hash tanda tangan adalah sha256.
berdosa
2
"Enkripsi kelas dunia * nol otentikasi = nol keamanan" gerv.net/security/self-signed-certs
x-yuri
4
Perhatikan bahwa algoritma tanda tangan yang digunakan pada sertifikat yang ditandatangani sendiri tidak relevan dalam memutuskan apakah itu dapat dipercaya atau tidak. Root CA certs ditandatangani sendiri. dan pada Mei 2018, masih banyak sertifikat CA root aktif yang ditandatangani SHA-1. Karena tidak masalah jika sertifikat mempercayai dirinya sendiri, atau bagaimana sertifikat itu memverifikasi kepercayaan itu. Anda bisa mempercayai sertifikat root / yang ditandatangani sendiri untuk yang dikatakannya, atau tidak. Lihat security.stackexchange.com/questions/91913/…
Andrew Henle
20

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.

Drakes
sumber
Bekerja pada macOS High Siera dan Chrome 58
Saqib Omer
Saya masih tidak yakin bagaimana CN memengaruhi pengaturan keseluruhan? Saya mencoba menjalankan ini sebagai localhostatau 127.0.0.1:port#apa yang sesuai CNuntuk sesuatu seperti ini.
DJ2
@ DJ2 Saya akan mengatur BASE_DOMAIN = “localhost”
Drakes
9

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.

joemillervi
sumber
2
Untuk pengguna Linux Anda harus mengubah jalur itu untuk konfigurasi. misalnya pada /etc/ssl/openssl.confkarya Ubuntu saat ini
kemunduran
Untuk satu-liner yang tidak mengharuskan Anda untuk menentukan lokasi openssl.cnf, lihat: stackoverflow.com/a/41366949/19163
vog
7

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
[email protected]

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

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

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
[email protected]

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

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

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 
mrkiril
sumber
2
Meskipun, proses ini terlihat rumit, ini adalah persis apa yang kita butuhkan untuk domain .dev, karena domain ini tidak mendukung sertifikat yang ditandatangani sendiri dan Chrome dan Firefox memaksa HSTS. Apa yang saya lakukan adalah mengikuti langkah-langkah ini, yaitu membuat CA, membuat sertifikat dan menandatanganinya dengan CA saya dan pada akhirnya mempercayai CA saya di browser. Terima kasih.
bajicdusko
1
Anda Tuan, adalah legenda. Homelab saya terima kasih!
antsyawn
6

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

nneko
sumber
6

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/[email protected]"

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

OkezieE
sumber
1
Semua argumen kecuali untuk SANs ... @ vog's jawaban mencakup juga (dan mendahului ini) (Ini memiliki bidang "Subjek" yang lebih lengkap diisi ...) (Bukan penggemar berat dari satu tahun kedaluwarsa juga)
Gert van den Berg
6

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.

pengguna327843
sumber
3

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 .

ThorSummoner
sumber
-1; ini sebagian besar bersinggungan dengan pertanyaan yang diajukan, dan juga melakukan pekerjaan yang buruk untuk memperjelas dari mana kutipan itu berasal.
Mark Amery
Ini menunjukkan penyediaan CA, Server / Sertifikat klien yang ditandatangani oleh CA, konfigurasikan untuk dibaca oleh mysqld pada host dengan apparmor. Ini mencontohkan kasus yang agak tidak berguna hosting ca, server, dan klien pada mesin yang sama, dan berbahaya mengekspos otoritas ca itu untuk proses mysqld. Pengaturan ini tidak masuk akal selain untuk menguji konfigurasi ssl di lingkungan pengujian. Untuk mengoperasikan CA internal, saya akan merekomendasikan gnuttls toolchain melalui openssl help.ubuntu.com/community/GnuTLS dan memiliki pemahaman yang baik tentang tl sebelum menangani kasus appsor mysqld +
ThorSummoner
3

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
Peter Jirak Eldritch
sumber