Sertifikasi akar sertifikat kadaluwarsa dan perpanjangan

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.

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:

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:

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

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

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

@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

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.

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.