Πώς να δημιουργήσετε κλειδί VPN πελάτη και να υποβάλετε CSR για υπογραφή

Αργά ή γρήγορα, ένας χρήστης VPN προσφέρεται να στείλει με email ένα ιδιωτικό κλειδί ώστε ο διαχειριστής να φτιάξει πιστοποιητικό, και αυτή ακριβώς η προσφορά είναι που πρέπει να αρνηθείτε. Η ροή που δουλεύει κρατά το κλειδί στον πελάτη από την πρώτη εντολή: ο πελάτης το δημιουργεί, στέλνει αίτημα υπογραφής πιστοποιητικού, ο εκδότης το επαληθεύει και το εγκρίνει, και το υπογεγραμμένο πιστοποιητικό επιστρέφει για να σταθεί δίπλα στο κλειδί που το δημιούργησε. Η λίστα ελέγχου παρακάτω αποτυγχάνει κλειστά σε κάθε βήμα, και αυτό είναι το νόημα, γιατί δύο από τα πέντε βήματα είναι εκείνα που οι άνθρωποι παραλείπουν όταν βιάζονται.

Βήμα 1: δημιουργήστε το κλειδί εκεί που θα ζήσει

Δημιουργήστε το στο μηχάνημα που θα κρατήσει το κλειδί και αφήστε το εκεί. Ένα κλειδί λογισμικού πηγαίνει σε αρχείο με περιοριστικές άδειες· ένα κλειδί με υποστήριξη υλικού ή σε διαχειριζόμενο χώρο αποθήκευσης δεν γίνεται ποτέ αρχείο, και η διαδρομή εγγραφής του είναι συνήθως ξεχωριστό εργαλείο και όχι εντολή OpenSSL. Όπως και να έχει, κανείς δεν χρειάζεται να δει το ιδιωτικό μισό.

Η ροή λογισμικού μοιάζει έτσι, με το κλειδί και το αίτημα να δημιουργούνται σε μία συνεδρία:

umask 077
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:3072 -out client.key
openssl req -new -key client.key -out client.csr -subj "/CN=alice-vpn/O=Example"

Η γραμμή umask έχει μεγαλύτερη σημασία απ' ό,τι φαίνεται. Χωρίς αυτήν το κλειδί γράφεται αναγνώσιμο από όλους σε σύστημα με προεπιλεγμένη άδεια, και το αντιγραφή του αρχείου αργότερα το διαδίδει. Η επαναχρησιμοποίηση υπάρχοντος κλειδιού είναι θεμιτή όταν είναι ήδη προστατευμένο και ταιριάζει με την πολιτική σας· το να δημιουργείτε νέο για κάθε συσκευή είναι ευκολότερο να αιτιολογηθεί.

Βήμα 2: βάλτε την ταυτότητα στο αίτημα, όχι στο email

Αποφασίστε τι πραγματικά επαληθεύει το VPN πριν δημιουργηθεί το αίτημα, γιατί αυτή η απάντηση ανήκει μέσα στο CSR. OpenVPN συνδέει παραδοσιακά την ταυτότητα του πελάτη με το κοινό όνομα του πιστοποιητικού, και εργαλεία όπως το strongSwan αντιστοιχίζουν μια συμβολοσειρά ταυτότητας με το subject ή ένα subject alternative name. Ένα email που λέει ότι με λένε alice δεν είναι απόδειξη, και ένα αίτημα του οποίου το subject λέει το ίδιο είναι μόνο ελαφρώς καλύτερο.

Προσθέστε ένα subject alternative name όταν ο επαληθευτής σας ελέγχει ένα, αφού η σύγχρονη αντιστοίχιση συχνά αγνοεί το παλιό CN:

openssl req -new -key client.key -out client.csr \
  -subj "/CN=alice-vpn/O=Example" \
  -addext "subjectAltName=DNS:alice-vpn"

Κρατήστε το CN σύντομο, σταθερό και δεμένο με τον λογαριασμό και όχι με μοντέλο φορητού. Ένα όνομα που περιέχει τον σειριακό αριθμό της συσκευής του χρήστη είναι πρόβλημα υποστήριξης που περιμένει την πρώτη αντικατάσταση υλικού.

Βήμα 3: επαληθεύστε το αίτημα πριν το υπογράψετε

Ο εκδότης επαληθεύει δύο διαφορετικά πράγματα, και το να τα συγχέετε είναι το κλασικό λάθος. Πρώτον, ότι το αίτημα είναι εσωτερικά συνεπές: η υπογραφή επαληθεύεται έναντι του δημόσιου κλειδιού που φέρει. Δεύτερον, ότι ο αιτών δικαιούται αυτό που ζητά το αίτημα, και σε αυτό κανένας κρυπτογραφικός έλεγχος δεν μπορεί να απαντήσει.

Το μηχανικό μέρος είναι μία εντολή, και θα πρέπει να εκτυπώνει αποτέλεσμα επαλήθευσης μαζί με το subject:

openssl req -in client.csr -noout -verify -subject
openssl req -in client.csr -noout -pubkey | openssl pkey -pubin -noout -text

Προσέξτε τι αποδεικνύει αυτό. Ένα αίτημα που επαληθεύεται δείχνει μόνο ότι ο αποστολέας είχε το αντίστοιχο ιδιωτικό κλειδί τη στιγμή της υποβολής· δεν αποδεικνύει ότι ο αποστολέας είναι το πρόσωπο που αναφέρεται στο subject, και δεν εξουσιοδοτεί την πρόσβαση σε ομάδα ή διαδρομή που ζητείται. Η αναθεώρηση εγγραφής είναι ξεχωριστή πύλη, και ένα αίτημα για ομάδα που κανείς δεν ενέκρινε πρέπει να απορρίπτεται αντί να επεξεργάζεται σιωπηλά.

Βήμα 4: εξουσιοδοτήστε και μετά υπογράψτε με ρητές επεκτάσεις

Η υπογραφή είναι εκεί όπου η CA αποφασίζει πολιτική αντί να δεχτεί το αίτημα κατά λέξη. Η εγκυρότητα, η χρήση κλειδιού και η επέκταση ρόλου ανήκουν σε αρχείο επεκτάσεων, όχι σε προεπιλογές που δεν θα θυμάστε έξι μήνες αργότερα. Ένα πιστοποιητικό πελάτη για έλεγχο ταυτότητας VPN χρειάζεται τον έλεγχο ταυτότητας πελάτη ως σκοπό του.

cat > client.ext <<'EOF'
basicConstraints = CA:FALSE
keyUsage = digitalSignature
extendedKeyUsage = clientAuth
EOF
openssl x509 -req -in client.csr -CA ca.crt -CAkey ca.key \
  -CAcreateserial -days 365 -extfile client.ext -out client.crt

Χρησιμοποιήστε το -CAserial με το υπάρχον αρχείο σειριακών αριθμών αν κάποιο χρησιμοποιείται ήδη, και κρατήστε το κλειδί της CA εκτός σύνδεσης ή σε όποιο προστατευμένο χώρο ορίζει η πολιτική σας. Οι σειριακοί αριθμοί πιστοποιητικών πρέπει να είναι μοναδικοί ανά εκδότη· η αναδημιουργία του αρχείου σειριακών από το μηδέν ρισκάρει συγκρούσεις που κάνουν την ανάκληση ασαφή.

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

Βήμα 5: εγκαταστήστε το δίπλα στο αντίστοιχο κλειδί και αποδείξτε το ζεύγος

Ο πελάτης λαμβάνει το πιστοποιητικό και την αλυσίδα του εκδότη, ποτέ κλειδί. Πριν συνδεθείτε, επιβεβαιώστε ότι το πιστοποιητικό πράγματι ταιριάζει με το κλειδί που βρίσκεται ήδη στον δίσκο, γιατί ένα αταίριαστο ζεύγος παράγει μια μπερδεμένη αποτυχία χειραψίας πολύ αργότερα:

openssl x509 -in client.crt -noout -pubkey | openssl pkey -pubin -outform DER | openssl sha256
openssl pkey -in client.key -pubout -outform DER | openssl sha256

Οι δύο συνόψεις πρέπει να ταιριάζουν. Έπειτα συνδεθείτε και επιβεβαιώστε ότι η ταυτότητα που καταγράφει ο διακομιστής είναι αυτή που εξουσιοδοτήσατε, και όχι απλώς ότι η σήραγγα σηκώθηκε. Αν χαθεί το κλειδί ή αντικατασταθεί η συσκευή, η απάντηση είναι ανάκληση συν νέο αίτημα από τη νέα συσκευή· το να ζητήσετε από τον διαχειριστή να στείλει πίσω κλειδί από αλλού δεν ανακτά το αρχικό και σπάει σιωπηλά το μοντέλο που έκανε το αίτημα ασφαλές.