Sertifikasi akar sertifikat kadaluwarsa dan perpanjangan


96

Pada tahun 2004, saya membuat otoritas sertifikasi kecil menggunakan OpenSSL di Linux dan skrip manajemen sederhana yang disediakan dengan OpenVPN. Sesuai dengan panduan yang saya temukan pada saat itu, saya menetapkan periode validitas untuk sertifikat CA root menjadi 10 tahun. Sejak itu, saya telah menandatangani banyak sertifikat untuk terowongan OpenVPN, situs web dan server e-mail, yang semuanya juga memiliki masa berlaku 10 tahun (ini mungkin salah, tetapi saya tidak tahu lebih baik pada saat itu).

Saya telah menemukan banyak panduan tentang pengaturan CA, tetapi hanya sedikit informasi tentang manajemennya, dan khususnya, tentang apa yang harus dilakukan ketika sertifikat CA root kedaluwarsa, yang akan terjadi beberapa waktu pada tahun 2014. Jadi saya memiliki yang berikut pertanyaan:

  • Akankah sertifikat yang memiliki masa berlaku yang diperpanjang setelah berakhirnya sertifikat CA akar menjadi tidak berlaku segera setelah yang terakhir berakhir, atau akankah mereka terus berlaku (karena mereka ditandatangani selama masa berlaku sertifikat CA)?
  • Operasi apa yang diperlukan untuk memperbarui sertifikat CA root dan memastikan transisi yang lancar selama berakhirnya?
    • Bisakah saya menandatangani ulang sertifikat CA root saat ini dengan periode validitas yang berbeda, dan mengunggah sertifikat yang baru ditandatangani ke klien sehingga sertifikat klien tetap valid?
    • Atau apakah saya perlu mengganti semua sertifikat klien dengan yang baru yang ditandatangani oleh sertifikat CA root baru?
  • Kapan sebaiknya sertifikat CA root diperbarui? Tutup kedaluwarsa, atau waktu yang wajar sebelum kedaluwarsa?
  • Jika pembaruan sertifikat CA root menjadi bagian utama dari pekerjaan, apa yang dapat saya lakukan lebih baik sekarang untuk memastikan transisi yang lebih lancar pada pembaruan berikutnya (tentu saja, kurang dari menetapkan masa berlaku 100 tahun, tentu saja)?

Situasi menjadi sedikit lebih rumit oleh kenyataan bahwa satu-satunya akses saya ke beberapa klien adalah melalui terowongan OpenVPN yang menggunakan sertifikat yang ditandatangani oleh sertifikat CA saat ini, jadi jika saya harus mengganti semua sertifikat klien, saya perlu menyalin file-file baru ke klien, restart terowongan, silangkan jari saya dan berharap itu muncul sesudahnya.

Jawaban:


142

Mempertahankan kunci pribadi yang sama pada root Anda CA memungkinkan semua sertifikat untuk terus memvalidasi berhasil terhadap root baru; yang Anda butuhkan hanyalah mempercayai root baru.

Hubungan penandatanganan sertifikat didasarkan pada tanda tangan dari kunci pribadi; menjaga kunci privat yang sama (dan, secara implisit, kunci publik yang sama) sambil menghasilkan sertifikat publik baru, dengan periode validitas baru dan atribut baru lainnya diubah sesuai kebutuhan, menjaga hubungan kepercayaan tetap di tempatnya. CRL juga dapat melanjutkan dari sertifikat lama ke sertifikat baru, seperti sertifikat, ditandatangani oleh kunci pribadi.


Jadi, mari kita verifikasi!

Buat CA root:

openssl req -new -x509 -keyout root.key -out origroot.pem -days 3650 -nodes

Hasilkan sertifikat anak dari itu:

openssl genrsa -out cert.key 1024
openssl req -new -key cert.key -out cert.csr

Tandatangani sertifikat anak:

openssl x509 -req -in cert.csr -CA origroot.pem -CAkey root.key -create_serial -out cert.pem
rm cert.csr

Semua diatur di sana, hubungan sertifikat normal. Mari memverifikasi kepercayaan:

# openssl verify -CAfile origroot.pem -verbose cert.pem
cert.pem: OK

Ok, jadi, sekarang misalkan 10 tahun berlalu. Mari kita buat sertifikat publik baru dari kunci privat root yang sama.

openssl req -new -key root.key -out newcsr.csr
openssl x509 -req -days 3650 -in newcsr.csr -signkey root.key -out newroot.pem
rm newcsr.csr

Dan .. apakah itu berhasil?

# openssl verify -CAfile newroot.pem -verbose cert.pem
cert.pem: OK

Tapi kenapa? Itu file yang berbeda, bukan?

# sha1sum newroot.pem
62577e00309e5eacf210d0538cd79c3cdc834020  newroot.pem
# sha1sum origroot.pem
c1d65a6cdfa6fc0e0a800be5edd3ab3b603e1899  origroot.pem

Ya, tetapi, itu tidak berarti bahwa kunci publik baru tidak secara kriptografis cocok dengan tanda tangan pada sertifikat. Nomor seri berbeda, modulus yang sama:

# openssl x509 -noout -text -in origroot.pem
        Serial Number:
            c0:67:16:c0:8a:6b:59:1d
...
            RSA Public Key: (1024 bit)
                Modulus (1024 bit):
                    00:bd:56:b5:26:06:c1:f6:4c:f4:7c:14:2c:0d:dd:
                    3c:eb:8f:0a:c0:9d:d8:b4:8c:b5:d9:c7:87:4e:25:
                    8f:7c:92:4d:8f:b3:cc:e9:56:8d:db:f7:fd:d3:57:
                    1f:17:13:25:e7:3f:79:68:9f:b5:20:c9:ef:2f:3d:
                    4b:8d:23:fe:52:98:15:53:3a:91:e1:14:05:a7:7a:
                    9b:20:a9:b2:98:6e:67:36:04:dd:a6:cb:6c:3e:23:
                    6b:73:5b:f1:dd:9e:70:2b:f7:6e:bd:dc:d1:39:98:
                    1f:84:2a:ca:6c:ad:99:8a:fa:05:41:68:f8:e4:10:
                    d7:a3:66:0a:45:bd:0e:cd:9d
# openssl x509 -noout -text -in newroot.pem
        Serial Number:
            9a:a4:7b:e9:2b:0e:2c:32
...
            RSA Public Key: (1024 bit)
                Modulus (1024 bit):
                    00:bd:56:b5:26:06:c1:f6:4c:f4:7c:14:2c:0d:dd:
                    3c:eb:8f:0a:c0:9d:d8:b4:8c:b5:d9:c7:87:4e:25:
                    8f:7c:92:4d:8f:b3:cc:e9:56:8d:db:f7:fd:d3:57:
                    1f:17:13:25:e7:3f:79:68:9f:b5:20:c9:ef:2f:3d:
                    4b:8d:23:fe:52:98:15:53:3a:91:e1:14:05:a7:7a:
                    9b:20:a9:b2:98:6e:67:36:04:dd:a6:cb:6c:3e:23:
                    6b:73:5b:f1:dd:9e:70:2b:f7:6e:bd:dc:d1:39:98:
                    1f:84:2a:ca:6c:ad:99:8a:fa:05:41:68:f8:e4:10:
                    d7:a3:66:0a:45:bd:0e:cd:9d

Mari kita melangkah lebih jauh untuk memverifikasi bahwa itu berfungsi dalam validasi sertifikat dunia nyata.

Jalankan instance Apache, dan mari kita coba (struktur file debian, sesuaikan yang diperlukan):

# cp cert.pem /etc/ssl/certs/
# cp origroot.pem /etc/ssl/certs/
# cp newroot.pem /etc/ssl/certs/
# cp cert.key /etc/ssl/private/

Kami akan menetapkan arahan ini pada VirtualHostmendengarkan pada 443 - ingat, newroot.pemsertifikat root bahkan tidak ada ketika cert.pemdibuat dan ditandatangani.

SSLEngine on
SSLCertificateFile /etc/ssl/certs/cert.pem
SSLCertificateKeyFile /etc/ssl/private/cert.key
SSLCertificateChainFile /etc/ssl/certs/newroot.pem

Mari kita lihat bagaimana openssl melihatnya:

# openssl s_client -showcerts -CAfile newroot.pem -connect localhost:443

Certificate chain
 0 s:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=server.lan
   i:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
 1 s:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
   i:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
-----BEGIN CERTIFICATE-----
MIICHzCCAYgCCQCapHvpKw4sMjANBgkqhkiG9w0BAQUFADBUMQswCQYDVQQGEwJB
...
-----END CERTIFICATE-----
(this should match the actual contents of newroot.pem)
...
Verify return code: 0 (ok)

Oke, dan bagaimana dengan browser yang menggunakan API crypto MS? Harus mempercayai root, pertama, lalu semuanya baik-baik saja, dengan nomor seri root baru:

akar baru

Dan, kita juga masih harus bekerja dengan root yang lama. Beralih konfigurasi Apache:

SSLEngine on
SSLCertificateFile /etc/ssl/certs/cert.pem
SSLCertificateKeyFile /etc/ssl/private/cert.key
SSLCertificateChainFile /etc/ssl/certs/origroot.pem

Lakukan restart penuh di Apache, memuat ulang tidak akan mengalihkan sertifikat dengan benar.

# openssl s_client -showcerts -CAfile origroot.pem -connect localhost:443

Certificate chain
 0 s:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=server.lan
   i:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
 1 s:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
   i:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
-----BEGIN CERTIFICATE-----
MIIC3jCCAkegAwIBAgIJAMBnFsCKa1kdMA0GCSqGSIb3DQEBBQUAMFQxCzAJBgNV
...
-----END CERTIFICATE-----
(this should match the actual contents of origroot.pem)
...
Verify return code: 0 (ok)

Dan, dengan browser MS crypto API, Apache menghadirkan root lama, tetapi root baru masih ada di root store tepercaya komputer. Secara otomatis akan menemukannya dan memvalidasi sertifikat terhadap root tepercaya (baru), meskipun Apache menghadirkan rantai yang berbeda (root lama). Setelah menghapus root baru dari root tepercaya dan menambahkan cert root asli, semuanya baik-baik saja:

akar tua


Jadi begitulah! Simpan kunci pribadi yang sama saat Anda memperbarui, tukar di root tepercaya yang baru, dan itu hampir semuanya berfungsi . Semoga berhasil!


2
Bagaimanapun, apa gunanya membuat sertifikat root baru jika Anda hanya akan menggunakan kembali kunci pribadi yang sama? Jika Anda terus melakukan ini berulang kali, lalu apa gunanya memiliki tanggal kedaluwarsa untuk sertifikat? Saya pikir kedaluwarsa root digunakan untuk memaksa admin untuk membuat kunci privat yang lebih baru (kemungkinan besar lebih kuat) yang lebih aman terhadap mesin yang semakin maju yang mencoba memecahkan kunci. Kunci 40 bit yang dibuat 20 tahun lalu tidak cukup aman untuk
jvhashe

2
@ jvhashe Jika sertifikat root tidak lagi cukup kuat secara kriptografis, maka Anda harus menyingkirkannya terlepas dari tanggal kedaluwarsanya. Jika Anda membuat root sendiri, tidak ada yang menghentikan Anda dari menetapkannya hingga ratusan tahun yang lalu ketika Anda tidak lagi berada di planet ini. Kedaluwarsa hampir tidak relevan pada sertifikat akar - dan untuk sertifikat anak, kedaluwarsa itu juga tidak benar-benar mengenai kekuatan kriptografis (tanyakan kepada CA yang siap mencabut semua sertifikat 1024-bit pada bulan Oktober) - lihat di sini untuk info lebih lanjut.
Shane Madden

3
Selain hal di atas, saya menemukan bahwa nomor seri harus sama agar metode ini berfungsi.
Scott Presnell

2
-set_serial 01- WTF ??? ANDA TIDAK BISA MENGGUNAKAN NOMOR SERI . Apakah Anda bahkan berkonsultasi dengan RFC 4158, Internet X.509 Public Key Infrastructure: Certification Path Building ? Atau apakah Anda hanya mengada-ada saja? Anda tidak tahu masalah yang Anda sebabkan di agen pengguna saat mereka mulai membangun jalur.

1
@ jww Apakah Anda membaca jawabannya? Itu hanya demonstrasi fakta bahwa kriptografi berfungsi. Perintah itu benar-benar hanya menghasilkan sertifikat pengujian yang dapat kami verifikasi nanti, untuk keperluan menguji hubungan antara sertifikat root yang lama dan yang baru. Jika seseorang adalah menggunakan perintah-perintah tersebut secara langsung, saya tentu berharap sesuatu istirahat, dan mereka menyadari bahwa mereka perlu memperhatikan konteks sesuatu sebelum membabi buta menjalankannya (atau terbang pegangan tentang apakah 01merupakan seri diterima di laboratorium).
Shane Madden

14

Saya perhatikan bahwa ekstensi CA mungkin hilang dalam sertifikat baru kunci CA asli. Ini bekerja lebih tepat untuk saya (itu menciptakan ./renewedselfsignedca.conf di mana ekstensi CA v3 didefinisikan, dan ca.key dan ca.crt diasumsikan sebagai kunci CA asli dan sertifikat):

openssl x509 -x509toreq -in ca.crt -signkey ca.key -out renewedselfsignedca.csr
echo -e "[ v3_ca ]\nbasicConstraints= CA:TRUE\nsubjectKeyIdentifier= hash\nauthorityKeyIdentifier= keyid:always,issuer:always\n" > renewedselfsignedca.conf
openssl x509 -req -days 1095 -in renewedselfsignedca.csr -signkey ca.key -out renewedselfsignedca.crt -extfile ./renewedselfsignedca.conf -extensions v3_ca

2
Ini merupakan tambahan yang sangat membantu. Jawaban yang benar-benar valid tidak menghasilkan sertifikat yang cukup kompatibel untuk saya jika Anda memiliki pengaturan sewenang-wenang pada root asli Anda ca.
Theuni

1
Diperbaiki, sangat membantu. Tambahan lain: seperti Scott Presnell dalam komentar untuk jawaban yang diterima, saya juga harus secara manual menentukan nomor seri heksadesimal dari sertifikat yang diperbarui sehingga cocok dengan yang lama. Ini berarti menambahkan -set_serial 0xdeadbeefabba(bukan no seri nyata :)) ke perintah x509 yang terakhir. Hanya saat itulah sertifikat klien saya berhasil memverifikasi terhadap sertifikat CA yang diperbarui.
JK Laiho

Metode ini lebih mudah karena menyimpan informasi yang sama dari sertifikat sebelumnya.
Lepe

Saya telah membuat skrip untuk solusi ini plus -set_serial - lihat jawaban saya
Wolfgang Fahl

Jawaban ini menyelamatkan saya dari banyak pekerjaan, setelah menghabiskan hampir sehari pada masalah yang mengharuskan ini, saya hampir menyerah, saya memberi tip kepada saya untuk ini!
Onitlikesonic

2

Mode dasar untuk memperpanjang periode root yang valid (Anda perlu X.509 publik dan kunci privat yang dikaitkan):

Hasilkan CSR dari kunci publik X.509 dan kunci pribadi:

openssl x509 -x509toreq -in XXX.crt -signkey XXX.key -out XXX.csr

Tandatangani kembali CSR dengan kunci pribadi:

openssl x509 -in XXX.csr -out XXX.crt -signkey XXX.key -req -days 365

1

@Bianconiglio plus -set_serial bekerja untuk saya. Server saya hanya intranet jadi saya tidak terlalu khawatir dengan apa efek sampingnya dan sekarang saya punya waktu untuk mengerjakan solusi yang "tepat".

Saya menggunakan skrip yang dapat dikonfigurasi berikut. Cukup atur variabel CACRT, CAKEY dan NEWCA.

# WF 2017-06-30
# https://serverfault.com/a/501513/162693
CACRT=SnakeOilCA.crt
CAKEY=SnakeOilCA.key
NEWCA=SnakeOilCA2017
serial=`openssl x509 -in $CACRT -serial -noout | cut -f2 -d=`
echo $serial
openssl x509 -x509toreq -in $CACRT -signkey $CAKEY -out $NEWCA.csr
echo -e "[ v3_ca ]\nbasicConstraints= CA:TRUE\nsubjectKeyIdentifier= hash\nauthorityKeyIdentifier= keyid:always,issuer:always\n" > $NEWCA.conf
openssl x509 -req -days 3650 -in $NEWCA.csr -set_serial 0x$serial -signkey $CAKEY -out $NEWCA.crt -extfile ./$NEWCA.conf -extensions v3_ca
openssl x509 -in $NEWCA.crt -enddate -serial -noout

0

Ketika sertifikat root Anda kedaluwarsa, demikian juga sertifikat yang telah Anda tanda tangani. Anda harus membuat sertifikat root baru dan menandatangani sertifikat baru dengannya. Jika Anda tidak ingin mengulangi prosesnya setiap beberapa tahun, satu-satunya pilihan nyata adalah memperpanjang tanggal valid pada root cert kira-kira sepuluh atau dua puluh tahun: Root yang saya hasilkan untuk saya gunakan sendiri, saya tetapkan dua puluh tahun.

Anda tidak dapat "memperbarui" sertifikat root. Yang dapat Anda lakukan adalah menghasilkan yang baru.

Hasilkan root baru setidaknya satu atau dua tahun sebelum yang lama Anda habis sehingga Anda punya waktu untuk berubah tanpa melawan tembok waktu jika terjadi kesalahan. Dengan begitu Anda dapat selalu sementara beralih kembali ke sertifikat lama sampai Anda mendapatkan masalah gigi Anda dengan yang baru diselesaikan.

Sejauh terowongan VPN berjalan, saya akan menyiapkan beberapa server yang diuji untuk bereksperimen sehingga Anda mengerti persis apa yang harus Anda lakukan sebelum melakukannya dengan mesin klien.


Balasan ini tampaknya menyarankan bahwa mungkin untuk memperbarui sertifikat root, dengan menggunakan kembali kuncinya. Tetapi saya menduga ini tidak berbeda dari mulai dari awal, karena sertifikat baru akan memiliki tanda tangan yang berbeda, dan karenanya tidak akan memvalidasi sertifikat klien yang ada.
Remy Blank

ya, Anda dapat memperpanjang periode yang valid ... dan kurang bekerja daripada membuat ulang semua pki, sertifikat klien, dan menelusuri kembali root baru ...
ggrandes

Bagian tentang penerbitan sertifikat entitas akhir yang baru belum tentu benar. Itu tergantung pada bagaimana Pengidentifikasi Kunci Otoritas (AKID) diwakili dalam CA bawahan dan sertifikat entitas akhir. Jika AKID didasarkan pada {Nama Terhormat, Nomor Seri} , maka kontinuitas akan tercapai. Juga lihat RFC 4518, Internet X.509 Infrastruktur Kunci Publik: Pembuatan Jalur Sertifikasi .

0

Kami memiliki masalah yang sama, dan itu dalam kasus kami karena server Debian sudah ketinggalan zaman, dan openSSL memiliki masalah ini:

https://en.wikipedia.org/wiki/Year_2038_problem

Versi OpenSSL terakhir yang tersedia untuk Debian 6 membawa masalah ini. Semua sertifikat yang dibuat setelah 23.01.2018 menghasilkan Vality: untuk 1901 tahun!

Solusinya adalah memperbarui OpenSSL. Anda dapat membuat lagi file konfigurasi (dengan sertifikat) untuk klien.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.