Προς την αυτοματοποίηση της έκδοσης SSL

Αρκετά συχνά πρέπει να δουλέψουμε με πιστοποιητικά SSL. Ας θυμηθούμε τη διαδικασία δημιουργίας και εγκατάστασης ενός πιστοποιητικού (στη γενική περίπτωση για τους περισσότερους).

• Βρείτε έναν πάροχο (έναν ιστότοπο όπου μπορούμε να αγοράσουμε SSL).
• Δημιουργία ΕΚΕ.
• Στείλτε το στον πάροχο.
• Επαληθεύστε την ιδιοκτησία του τομέα.
• Πάρτε ένα πιστοποιητικό.
• Μετατρέψτε το πιστοποιητικό στην επιθυμητή φόρμα (προαιρετικό). Για παράδειγμα, από το pem στο PKCS #12.
• Εγκαταστήστε το πιστοποιητικό στον διακομιστή web.

Σχετικά γρήγορο, εύκολο και κατανοητό. Αυτή η επιλογή είναι αρκετά κατάλληλη εάν έχουμε το πολύ δώδεκα έργα. Τι γίνεται αν υπάρχουν περισσότερα από αυτά και έχουν τουλάχιστον τρία περιβάλλοντα; Κλασική dev - σκηνοθεσία - παραγωγή. Σε αυτή την περίπτωση, αξίζει να σκεφτείτε την αυτοματοποίηση αυτής της διαδικασίας. Προτείνω να εμβαθύνουμε λίγο στο πρόβλημα και να βρούμε μια λύση που θα ελαχιστοποιεί περαιτέρω τον χρόνο που δαπανάται για τη δημιουργία και τη διατήρηση πιστοποιητικών. Το άρθρο θα περιέχει μια ανάλυση του προβλήματος και έναν μικρό οδηγό για την επανάληψη.

Θα κάνω κράτηση εκ των προτέρων: η κύρια εξειδίκευση της εταιρείας μας είναι το .net και, κατά συνέπεια, το IIS και άλλα που σχετίζονται με βίδες. Επομένως, ο πελάτης ACME και όλες οι ενέργειες για αυτόν θα περιγραφούν επίσης ως προς τη χρήση των παραθύρων.

Για ποιους είναι σχετικό και κάποια βασικά δεδομένα

Εταιρεία Κ εκπροσωπούμενη από τον συγγραφέα. URL (για παράδειγμα): company.tld

Το Project X είναι ένα από τα έργα μας, στο οποίο κατέληξα στο συμπέρασμα ότι πρέπει ακόμα να προχωρήσουμε προς τη μέγιστη εξοικονόμηση χρόνου όταν εργαζόμαστε με πιστοποιητικά. Αυτό το έργο έχει τέσσερα περιβάλλοντα: dev, δοκιμή, σκηνοθεσία και παραγωγή. Το Dev και το test είναι με το μέρος μας, η σκηνή και η παραγωγή είναι στην πλευρά του πελάτη.

Ένα χαρακτηριστικό του έργου είναι ότι διαθέτει μεγάλο αριθμό λειτουργικών μονάδων που είναι διαθέσιμα ως υποτομείς.

Δηλαδή έχουμε την παρακάτω εικόνα:

Dev
Δοκιμή
Σκαλωσιά
παραγωγή

projectX.dev.company.tld
projectX.test.company.tld
staging.projectX.tld
projectX.tld

module1.projectX.dev.company.tld
module1.projectX.test.company.tld
module1.staging.projectX.tld
module1.projectX.tld

module2.projectX.dev.company.tld
module2.projectX.test.company.tld
module2.staging.projectX.tld
module2.projectX.tld

...
...
...
...

moduleN.projectX.dev.company.tld
moduleN.projectX.test.company.tld
moduleN.staging.projectX.tld
moduleN.projectX.tld

Για την παραγωγή, χρησιμοποιείται ένα αγορασμένο πιστοποιητικό μπαλαντέρ, δεν υπάρχουν ερωτήσεις εδώ. Αλλά καλύπτει μόνο το πρώτο επίπεδο του υποτομέα. Αντίστοιχα, εάν υπάρχει πιστοποιητικό για το *.projectX.tld, τότε θα λειτουργήσει για το staging.projectX.tld, αλλά όχι για το module1.staging.projectX.tld. Δεν θέλω να αγοράσω ξεχωριστό.

Και αυτό συμβαίνει μόνο στο παράδειγμα ενός έργου μιας εταιρείας. Και το έργο, φυσικά, δεν είναι μόνο.

Οι γενικοί λόγοι για την αντιμετώπιση αυτού του ζητήματος μοιάζουν κάπως έτσι:

• Πρόσφατα Η Google πρότεινε τη μείωση της μέγιστης περιόδου ισχύος των πιστοποιητικών SSL. Με όλες τις συνέπειες.
• Να διευκολύνει τη διαδικασία έκδοσης και διατήρησης SSL για τις εσωτερικές ανάγκες των έργων και της εταιρείας συνολικά.
• Κεντρική αποθήκευση εγγραφών πιστοποιητικών, η οποία λύνει εν μέρει το πρόβλημα της επικύρωσης τομέα με χρήση DNS και την επακόλουθη αυτόματη ανανέωση, καθώς και το πρόβλημα της εμπιστοσύνης του πελάτη. Ωστόσο, το CNAME είναι πιο αξιόπιστο στον διακομιστή της εταιρείας συνεργάτη/εκτελεστή παρά σε έναν πόρο τρίτου μέρους.
• Λοιπόν, τελικά, σε αυτή την περίπτωση, η φράση «καλύτερα να έχεις παρά να μην έχεις» ταιριάζει απόλυτα.

Επιλογή παρόχου SSL και Προπαρασκευαστικά Βήματα

Από τις διαθέσιμες επιλογές για δωρεάν πιστοποιητικά SSL, εξετάστηκαν το cloudflare και το letsencrypt. Το DNS για αυτό (και ορισμένα άλλα έργα) φιλοξενείται από το cloudflare, αλλά δεν είμαι λάτρης της χρήσης των πιστοποιητικών τους. Ως εκ τούτου, αποφασίστηκε να χρησιμοποιηθεί letsencrypt.
Για να δημιουργήσετε ένα πιστοποιητικό SSL με χαρακτήρες μπαλαντέρ, πρέπει να επαληθεύσετε την ιδιοκτησία του τομέα. Αυτή η διαδικασία περιλαμβάνει τη δημιουργία κάποιας εγγραφής DNS (TXT ή CNAME), με την επακόλουθη επαλήθευση κατά την έκδοση πιστοποιητικού. Το Linux έχει ένα βοηθητικό πρόγραμμα − certbot, το οποίο σας επιτρέπει να αυτοματοποιήσετε εν μέρει (ή πλήρως για ορισμένους παρόχους DNS) αυτή τη διαδικασία. Για Windows το ίδιο από βρέθηκε και δοκιμάστηκε επιλογές για πελάτες ACME στις οποίες συμβιβάστηκα WinACME.

Και η εγγραφή για τον τομέα έχει δημιουργηθεί, ας προχωρήσουμε στη δημιουργία ενός πιστοποιητικού:

Μας ενδιαφέρει το τελευταίο συμπέρασμα, δηλαδή οι διαθέσιμες επιλογές για την επαλήθευση της ιδιοκτησίας τομέα για την έκδοση πιστοποιητικού μπαλαντέρ:

1. Μη αυτόματη δημιουργία εγγραφών DNS (δεν υποστηρίζεται η αυτόματη ενημέρωση)
2. Δημιουργία εγγραφών DNS χρησιμοποιώντας τον διακομιστή acme-dns (για περισσότερες λεπτομέρειες, βλ εδώ.
3. Δημιουργία εγγραφών DNS χρησιμοποιώντας το δικό σας σενάριο (παρόμοιο με το plugin cloudflare για certbot).

Με την πρώτη ματιά, το τρίτο σημείο είναι αρκετά κατάλληλο, αλλά αν ο πάροχος DNS δεν υποστηρίζει αυτήν τη λειτουργία; Και χρειαζόμαστε μια γενική υπόθεση. Και η γενική περίπτωση είναι οι εγγραφές CNAME, τις υποστηρίζουν όλοι. Επομένως, σταματάμε στο σημείο 2 και πηγαίνουμε στη διαμόρφωση του διακομιστή ACME-DNS μας.

Διαδικασία ρύθμισης διακομιστή ACME-DNS και έκδοσης πιστοποιητικού

Για παράδειγμα, δημιούργησα τον τομέα 2nd.pp.ua και θα τον χρησιμοποιήσω στο μέλλον.

Υποχρεωτική απαίτηση για τη σωστή λειτουργία του διακομιστή είναι η δημιουργία εγγραφών NS και A για τον τομέα του. Και η πρώτη δυσάρεστη στιγμή που συνάντησα είναι ότι το cloudflare (τουλάχιστον σε ελεύθερη λειτουργία) δεν σας επιτρέπει να δημιουργήσετε ταυτόχρονα μια εγγραφή NS και A για τον ίδιο κεντρικό υπολογιστή. Όχι ότι αυτό είναι πρόβλημα, αλλά σε δεσμό είναι δυνατό. Η υποστήριξη απάντησε ότι το πάνελ τους δεν το επιτρέπει. Δεν πειράζει, ας δημιουργήσουμε δύο καταχωρήσεις:

acmens.2nd.pp.ua. IN A 35.237.128.147
acme.2nd.pp.ua. IN NS acmens.2nd.pp.ua.

Σε αυτό το στάδιο, θα πρέπει να επιλύσουμε τον κεντρικό υπολογιστή acmens.2nd.pp.ua.

$ ping acmens.2nd.pp.ua
PING acmens.2nd.pp.ua (35.237.128.147) 56(84) bytes of data

Αλλά acme.2nd.pp.ua δεν θα επιλυθεί, καθώς ο διακομιστής DNS που το εξυπηρετεί δεν εκτελείται ακόμη.

Οι εγγραφές έχουν δημιουργηθεί, ας προχωρήσουμε στη ρύθμιση και εκκίνηση του διακομιστή ACME-DNS. Θα το ζήσω σε διακομιστή ubuntu λιμενεργάτης δοχείο, αλλά μπορείτε να το τρέξετε οπουδήποτε υπάρχει golang. Τα Windows είναι επίσης καλά, αλλά προτιμώ έναν διακομιστή Linux.

Δημιουργήστε τους απαραίτητους καταλόγους και αρχεία:

$ mkdir config
$ mkdir data
$ touch config/config.cfg

Ας χρησιμοποιήσουμε το vim με τον αγαπημένο σας επεξεργαστή κειμένου και ας επικολλήσουμε το δείγμα στο config.cfg διαμόρφωση.

Για επιτυχημένη εργασία, αρκεί να διορθώσετε τις ενότητες γενικών και api:

[general]
listen = "0.0.0.0:53"
protocol = "both"
domain = "acme.2nd.pp.ua"
nsname = "acmens.2nd.pp.ua" 
nsadmin = "admin.2nd.pp.ua" 
records = 
    "acme.2nd.pp.ua. A 35.237.128.147",
    "acme.2nd.pp.ua. NS acmens.2nd.pp.ua.",                                                                                                                                                                                                  ]
...
[api]
...
tls = "letsencrypt"
…

Επίσης, προαιρετικά, δημιουργήστε ένα αρχείο docker-compose στον κύριο κατάλογο της υπηρεσίας:

version: '3.7'
services:
  acmedns:
    image: joohoi/acme-dns:latest
    ports:
      - "443:443"
      - "53:53"
      - "53:53/udp"
      - "80:80"
    volumes:
      - ./config:/etc/acme-dns:ro
      - ./data:/var/lib/acme-dns

Ετοιμος. Μπορείτε να τρέξετε.

$ docker-compose up -d

Σε αυτό το στάδιο, ο κεντρικός υπολογιστής θα πρέπει να αρχίσει να επιλύει acme.2nd.pp.uaκαι εμφανίζονται 404 στις https://acme.2nd.pp.ua

$ ping acme.2nd.pp.ua
PING acme.2nd.pp.ua (35.237.128.147) 56(84) bytes of data.

$ curl https://acme.2nd.pp.ua
404 page not found

Εάν αυτό δεν εμφανίζεται - docker logs -f <container_name> για να βοηθήσω, καλά, τα αρχεία καταγραφής είναι αρκετά ευανάγνωστα.

Μπορούμε να ξεκινήσουμε τη δημιουργία ενός πιστοποιητικού. Ανοίξτε το powershell ως διαχειριστής και εκτελέστε το winacme. Μας ενδιαφέρουν οι εκλογές:

• Μ: Δημιουργία νέου πιστοποιητικού (πλήρες επιλογές)
• 2: Χειροκίνητη είσοδος
• 2: [dns-01] Δημιουργία εγγραφών επαλήθευσης με το acme-dns (https://github.com/joohoi/acme-dns)
• Όταν ερωτηθείτε σχετικά με έναν σύνδεσμο προς τον διακομιστή ACME-DNS, εισαγάγετε τη διεύθυνση URL του δημιουργημένου διακομιστή (https) ως απάντηση. URL του διακομιστή acme-dns: https://acme.2nd.pp.ua

Σε απάντηση, ο πελάτης εκδίδει μια εγγραφή που πρέπει να προστεθεί στον υπάρχοντα διακομιστή DNS (εφάπαξ διαδικασία):

[INFO] Creating new acme-dns registration for domain 1nd.pp.ua

Domain:              1nd.pp.ua
Record:               _acme-challenge.1nd.pp.ua
Type:                   CNAME
Content:              c82a88a5-499f-464f-96e4-be7f606a3b47.acme.2nd.pp.ua.
Note:                   Some DNS control panels add the final dot automatically.
                           Only one is required.

Δημιουργούμε την απαραίτητη καταχώρηση και βεβαιωνόμαστε ότι δημιουργήθηκε σωστά:

$ dig CNAME _acme-challenge.1nd.pp.ua +short
c82a88a5-499f-464f-96e4-be7f606a3b47.acme.2nd.pp.ua.

Επιβεβαιώνουμε ότι έχουμε δημιουργήσει την απαιτούμενη καταχώρηση στο winacme και συνεχίζουμε τη διαδικασία δημιουργίας πιστοποιητικού:

Περιγράφεται ο τρόπος χρήσης του certbot ως πελάτη εδώ.

Αυτό ολοκληρώνει τη διαδικασία δημιουργίας ενός πιστοποιητικού, μπορείτε να το εγκαταστήσετε σε έναν διακομιστή web και να το χρησιμοποιήσετε. Εάν, κατά τη δημιουργία ενός πιστοποιητικού, δημιουργήσετε επίσης μια εργασία στον προγραμματιστή, τότε στο μέλλον η διαδικασία ενημέρωσης του πιστοποιητικού θα πραγματοποιηθεί αυτόματα.

Πηγή: www.habr.com