Get best of the week

Manajemen sertifikat SSL: dari kekacauan pada ratusan server ke solusi terpusat

Apa yang ada di balik kata-kata "sekolah online terbesar di Eropa"? Di satu sisi, ini adalah seribu pelajaran per jam, 10 ribu guru, 100 ribu siswa. Dan bagi saya, seorang insinyur infrastruktur, ini juga mencakup 200+ server, ratusan layanan (mikro dan tidak terlalu), nama-nama domain dari tingkat 2 hingga 6. Di mana-mana Anda memerlukan SSL dan, karenanya, sertifikat untuk itu.



Sebagian besar, kami menggunakan sertifikat Mari Enkripsi. Keuntungan mereka adalah bahwa mereka gratis, dan tanda terima sepenuhnya otomatis. Di sisi lain, mereka memiliki fitur: pendek - hanya tiga bulan - validitas. Karenanya, mereka harus sering diperbarui. Kami mencoba mengotomatiskannya, tetapi masih ada banyak pekerjaan manual, dan sesuatu terus-menerus rusak. Setahun yang lalu, kami menemukan metode yang sederhana dan dapat diandalkan untuk memperbarui tumpukan sertifikat ini dan sejak itu kami lupa tentang masalah ini.

Dari satu sertifikat di satu server ke ratusan di beberapa pusat data


Sekali waktu hanya ada satu server. Dan di atasnya hidup seekor certbot, yang bekerja dari bawah mahkota. Kemudian satu server berhenti untuk mengatasi beban, sehingga server lain muncul. Dan kemudian semakin banyak. Masing-masing dari mereka memiliki sertifikat sendiri dengan set nama yang unik, dan di mana-mana diperlukan untuk mengkonfigurasi pembaruan mereka. Di suatu tempat selama ekstensi, mereka menyalin sertifikat yang ada, tetapi lupa tentang pembaruan.

Untuk mendapatkan sertifikat Let's Encrypt, Anda harus mengonfirmasi kepemilikan nama domain yang ditentukan dalam sertifikat. Ini biasanya dilakukan dengan permintaan HTTP terbalik.


Berikut adalah beberapa kesulitan standar yang kami temui ketika kami tumbuh:

  • : . .
  • HTTP. , . . - LDAP. - . .

Di beberapa tempat, sertifikat yang ditandatangani sendiri telah digunakan cukup lama, dan ini sepertinya solusi yang bagus di tempat-tempat di mana otentikasi tidak diperlukan - misalnya, untuk pengujian internal. Untuk mencegah browser melaporkan “situs mencurigakan” secara konstan, Anda hanya perlu menambahkan sertifikat root kami ke daftar yang tepercaya, dan intinya ada di topi. Tetapi kemudian timbul kesulitan di sini juga.



Masalahnya adalah bahwa di BrowserStack, yang digunakan penguji, tidak mungkin untuk menambahkan sertifikat ke daftar tepercaya untuk setidaknya iPad, Mac, iPhone. Jadi penguji harus memasang peringatan yang selalu muncul tentang situs berbahaya.

Cari solusinya


Tentu saja, pertama-tama, Anda perlu melakukan pemantauan untuk mencari tahu tentang sertifikat yang berakhir bukan ketika mereka sudah berakhir, tetapi sedikit lebih awal. Baiklah. Pemantauannya adalah, kita sekarang tahu bahwa sertifikat akan segera berakhir di sana-sini. Dan sekarang apa yang bisa saya lakukan?


Big Ear adalah bot lama yang tidak akan merusak sertifikat.

Dan mari kita gunakan sertifikat wildcard? Ayo! Mari Enkripsi sudah mengeluarkan mereka. Benar, Anda harus mengonfigurasi konfirmasi kepemilikan domain melalui DNS. Dan DNS kami tinggal di AWS Route53. Dan Anda harus menguraikan detail akses di AWS di semua server. Dan dengan munculnya server baru, salin semua ekonomi ini di sana juga.

Nah, nama level 3 dicakup oleh wildcard. Dan apa yang harus dilakukan dengan nama-nama tingkat 4 dan lebih tinggi? Kami memiliki banyak tim yang terlibat dalam pengembangan berbagai layanan. Sekarang adalah kebiasaan untuk membagi frontend dan backend. Dan jika frontend mendapatkan nama tingkat 3 seperti service.skyeng.ru , maka backend mencoba untuk memberikan nama api.service.skyeng.ru . Hmm, mungkin mereka melarang mereka untuk terus melakukan ini? Ide yang hebat! Dan apa yang harus dilakukan dengan lusinan yang sudah ada? Mungkinkah dengan tangan besi untuk mengarahkan mereka semua menjadi satu nama domain? Ganti semua nama dari berbagai tingkatan ini dengan URL seperti skyeng.ru/service. Secara teknis, ini merupakan opsi, tetapi berapa lama? Dan bagaimana bisnis dapat membenarkan perlunya tindakan seperti itu? Kami memiliki 30+ tim pengembangan, membujuk semua orang - ini akan memakan waktu setidaknya enam bulan. Dan kami menciptakan satu titik kegagalan. Suka atau tidak suka, ini adalah keputusan yang kontroversial.

Gagasan lain apa yang ada? ... Mungkin satu sertifikat dapat dibuat di mana kita termasuk semuanya? Dan kami akan menginstalnya di semua server. Ini bisa menjadi solusi untuk masalah kami, tetapi Let's Encrypt memungkinkan Anda hanya memiliki 100 nama dalam sertifikat, dan kami sudah memiliki lebih dari satu layanan microser.

Apa yang harus dilakukan dengan penguji? Mereka tidak menemukan apa pun, tetapi mereka terus mengeluh. Semua omong kosong kecuali lebah. Lebah juga sampah, tetapi ada banyak. Setiap pengembang atau penguji diberikan server uji - kami menyebutnya pengujian. Pemeriksaan bukanlah lebah, tetapi sudah ada lebih dari seratus. Dan untuk setiap proyek dikerahkan. Itu saja. Dan jika untuk dijual Anda membutuhkan sertifikat N, maka ada jumlah yang sama untuk setiap pengujian. Sejauh ini, mereka menandatangani sendiri. Akan lebih bagus untuk menggantinya dengan yang asli ...

Dua buku pedoman dan satu sumber kebenaran


Angsa, kanker, dan tombak tidak akan membawa gerobak ke mana pun. Kami membutuhkan pusat kendali server tunggal . Dalam kasus kami, ini adalah Ansible. Certbot pada setiap server itu jahat. Biarkan semua sertifikat disimpan di satu tempat. Jika di suatu tempat seseorang membutuhkan sertifikat, maka datanglah ke tempat ini dan ambil versi terbaru dari rak. Dan kami akan memastikan bahwa sertifikat selalu mutakhir di toko ini.

Detail akses AWS juga hanya ada di satu tempat. Karenanya, pertanyaan hilang, seperti menyiapkan AWS CLI pada server baru, yang memiliki akses ke Route53 dan sejenisnya.

Semua sertifikat yang diperlukan dijelaskan dalam satu file dalam Kemungkinan dalam format YAML:

    certificates:
      - common_name: skyeng.ru
        alt_names:
          - *.skyeng.ru
      - common_name: olympiad.skyeng.ru
        alt_names:
          - *.olympiad.skyeng.ru
          - api.content.olympiad.skyeng.ru
          - games.skyeng.ru
      - common_name: skyeng.tech
        alt_names:
          - *.skyeng.tech

      .  .  .

Satu buku pedoman diluncurkan secara berkala, yang melewati daftar ini dan melakukan kerja kerasnya - pada dasarnya sama dengan Certbot:

  • membuat akun dengan Let's Encrypt Certificate Authority
  • menghasilkan kunci pribadi
  • menghasilkan sertifikat (belum ditandatangani) - yang disebut permintaan penandatanganan sertifikat
  • mengirimkan permintaan penandatanganan
  • menerima tantangan DNS
  • menempatkan catatan yang diterima dalam DNS
  • mengirimkan permintaan penandatanganan lagi
  • dan, setelah akhirnya menerima sertifikat yang ditandatangani, menaruhnya di toko.

Playbook dilakukan sekali sehari. Jika ia tidak dapat memperbarui sertifikat apa pun karena alasan apa pun - baik itu masalah jaringan atau kesalahan di sisi Let's Encrypt - ini bukan masalah. Akan diperbarui waktu berikutnya.

Sekarang, ketika SSL diperlukan pada beberapa host layanan, Anda dapat pergi ke repositori ini dan mendapatkan beberapa file dari sana - operasi paling sederhana yang dilakukan playbook kedua ... Sertifikat apa yang diperlukan pada host ini dijelaskan dalam parameter host ini, dalam inventaris / host_vars / server .yml :

    certificates:
      - common_name: skyeng.ru
        handler: reload nginx
      - common_name: crm.skyeng.ru

      .  .  .

Jika file telah berubah, maka Ansible menarik sebuah kait - itu adalah tipikal untuk me-restart Nginx (dalam kasus kami, ini adalah tindakan default). Dan dengan cara yang sama, Anda dapat memperoleh sertifikat dari CA lain yang menggunakan protokol ACME.

Total


  • Kami memiliki banyak konfigurasi berbeda. Sesuatu terus-menerus pecah. Seringkali saya harus memanjat server dan mencari tahu apa yang terjatuh lagi.
  • Sekarang kami memiliki dua buku pedoman dan semuanya direkam di satu tempat. Semuanya bekerja seperti jam. Hidup menjadi lebih membosankan.

Pengujian


Ya, bagaimana dengan penguji dengan pengujian mereka? Setiap pengembang atau penguji diberikan server pengujian pribadi - pengujian. Saat ini ada sekitar 200 dari mereka. Mereka memiliki nama formulir test-y123.skyeng.link , di mana 123 adalah nomor pengujian. Membuat dan menghapus pengujian otomatis. Salah satu komponen tindakan adalah pemasangan sertifikat SSL di atasnya. Sertifikat SSL dibuat sebelumnya, dengan nama berdasarkan templat:

    ssl_cert_pattern:
      - *
      - *.auth
      - *.bill

      .  .  .

Hanya sekitar 30 nama. Jadi sertifikat itu datang dengan nama

    test-y123.skyeng.link
    *.test-y123.skyeng.link
    *.auth.test-y123.skyeng.link
    *.bill.test-y123.skyeng.link

dll.

Setelah pemecatan pengembang atau penguji, pengujiannya dihapus. Sertifikat tetap siap digunakan. Itu semua yang disimpan. Anda sendiri tahu di mana ia diuraikan menjadi host; Anda tahu caranya.

PS


Repositori dengan kode .

Mungkin juga menarik untuk membaca tentang topik ini bagaimana Stack Overflow beralih ke HTTPS :

  • Ratusan domain dari berbagai tingkatan
  • Soket web
  • Banyak API HTTP (masalah proxy)
  • Lakukan segalanya dan jangan jatuhkan kinerja

Jika Anda memiliki pertanyaan, tulis di komentar, dengan senang hati saya akan menjawab.

More articles:


All Articles