Χρησιμοποιήστε την υπάρχουσα εταιρική σας CA για τους ομότιμους του OpenVPN
Το Easy-RSA είναι ευκολία, όχι απαίτηση. Εκδώστε ξεχωριστούς ρόλους, συνδέστε τις εισόδους εμπιστοσύνης, παραδώστε ενδιάμεσα πιστοποιητικά και αποδείξτε ποιους ομότιμους δέχεται το τούνελ.
Τίποτα στο OpenVPN δεν απαιτεί το πιστοποιητικό να προέρχεται από το Easy-RSA, και ένας στόλος που διαθέτει ήδη οργανωτική PKI συνήθως δεν θα έπρεπε να χτίσει δεύτερη. Η πραγματική δουλειά δεν είναι η επιλογή εργαλείου αλλά η απόφαση τι σημαίνουν οι ταυτότητες που εκδόθηκαν, ποιους ομότιμους δέχεται το τούνελ και πώς φτάνουν η ανανέωση και η ανάκληση στον επαληθευτή. Περάστε τα πέντε βήματα παρακάτω με τη σειρά, γιατί ένα μεταγενέστερο βήμα δεν μπορεί να διορθώσει μια απόφαση ρόλου που ελήφθη στο πρώτο.
Εκδώστε δύο ρόλους αντί για μία κοινή ταυτότητα
Κάθε ομότιμος χρειάζεται το δικό του πιστοποιητικό και αντίστοιχο ιδιωτικό κλειδί. Ζητήστε από την ομάδα PKI μια ταυτότητα διακομιστή με χρήση διακομιστή και ξεχωριστές ταυτότητες πελάτη με χρήση πελάτη, ώστε το τούνελ να μπορεί να τις διακρίνει κατά τη χειραψία.
Αντισταθείτε στις συντομεύσεις που εμφανίζονται υπό πίεση προθεσμιών. Ένα κλειδί διακομιστή ιστού που αντιγράφεται σε φορητούς υπολογιστές εξαλείφει τη διάκριση από την οποία εξαρτάται ο έλεγχος ρόλου, και ένα κλειδί υπογραφής CA εγκατεστημένο σε τελικό σημείο VPN μετατρέπει έναν παραβιασμένο κεντρικό υπολογιστή σε παραβιασμένη ιεραρχία. Ένα πακέτο PKCS12 μπορεί να μεταφέρει κλειδί τελικού σημείου και την αλυσίδα του, αλλά ποτέ δεν παρέχει άδεια επαναχρησιμοποίησης αυτής της ταυτότητας σε άλλο ρόλο.
Συνδέστε τις εισόδους εμπιστοσύνης σε κάθε πλευρά
Ο πελάτης και ο διακομιστής χρειάζονται ο καθένας μια άγκυρα εμπιστοσύνης, τη δική του ταυτότητα και μια ρητή προσδοκία ρόλου. Ένα απόσπασμα πελάτη που δηλώνει και τα τρία μοιάζει με αυτό.
client
ca /etc/openvpn/pki/issuing-root.pem
cert /etc/openvpn/pki/device-17.crt
key /etc/openvpn/pki/device-17.key
remote-cert-tls server
verify-x509-name vpn.corp.example name
crl-verify /etc/openvpn/pki/issuing.crlΗ πλευρά του διακομιστή το καθρεφτίζει με remote-cert-tls client και το δικό της πιστοποιητικό, και αυτό ακριβώς εμποδίζει ένα πιστοποιητικό πελάτη να γίνει δεκτό ως διακομιστής. Ο έλεγχος ονόματος είναι ξεχωριστή απόφαση από τον έλεγχο ρόλου. Διαβάστε την αναπτυγμένη διαμόρφωση για να δείτε ποιο πεδίο συγκρίνεται, αντί να υποθέσετε αντιστοίχιση ονόματος κεντρικού υπολογιστή τύπου προγράμματος περιήγησης. Και οι δύο πλευρές θα πρέπει επίσης να δηλώνουν ρητά σε ποιον εκδότη έχουν εμπιστοσύνη, γιατί μια κοινή διαδρομή αρχείου σε όλο τον στόλο δεν είναι το ίδιο με μια κοινή πολιτική.
Παραδώστε ενδιάμεσα πιστοποιητικά χωρίς να διευρύνετε την εμπιστοσύνη
Οι δύο πλευρές δεν χρειάζεται να μοιράζονται μία αλυσίδα έκδοσης. Όταν ένας ομότιμος παρουσιάζει πιστοποιητικό υπογεγραμμένο από ενδιάμεσο, η πλευρά επαλήθευσης χρειάζεται αυτόν τον ενδιάμεσο διαθέσιμο, και το OpenVPN διακρίνει την είσοδο άγκυρας εμπιστοσύνης από τα πρόσθετα πιστοποιητικά που χρησιμοποιούνται για τη συμπλήρωση μιας τοπικά παρουσιασμένης αλυσίδας. Η αναφορά επιλογών TLS του OpenVPN 2.6 τεκμηριώνει και τα δύο.
Ένα ενδιάμεσο CA δεν είναι από μόνο του πρόβλημα, αλλά μια ευρεία εταιρική ρίζα που ρίχνεται στη δέσμη εμπιστοσύνης είναι. Όσο ευρύτερη είναι η άγκυρα, τόσο περισσότερα πιστοποιητικά περνούν τη δοκιμή αλυσίδας, και ένας έλεγχος ρόλου δεν το μετατρέπει σε κατάλογο εξουσιοδοτημένου προσωπικού. Στενέψτε την άγκυρα στον εκδότη που όντως υπογράφει ταυτότητες VPN όπου το επιτρέπει η ιεραρχία. Αν δεν το επιτρέπει, τεκμηριώστε την ευρύτερη άγκυρα ως σκόπιμα αποδεκτό κίνδυνο αντί να την αφήσετε σιωπηρή.
Συμφωνήστε με την ομάδα PKI για το πώς η ανανέωση και η ανάκληση φτάνουν στους επαληθευτές VPN, περιλαμβάνοντας ποιοι εκδότες μετρούν και ποιος δημοσιεύει τον κατάλογο. Ένα σημείο διανομής CRL ενσωματωμένο σε πιστοποιητικό είναι οδηγία, όχι απόδειξη ότι κάτι το ανέκτησε.
Αποφασίστε πώς φτάνει πραγματικά η ανάκληση
Το crl-verify κάνει τον επαληθευτή να συμβουλεύεται ένα αρχείο ή τελικό σημείο, και αυτή η ρύθμιση χρειάζεται ιδιοκτήτη και διαδρομή ανανέωσης. Ένας κατάλογος που αντιγράφεται μία φορά κατά την ανάπτυξη σταματά σιωπηλά να σας προστατεύει την πρώτη φορά που ανακαλείται ένα πιστοποιητικό.
Καταγράψτε τον αναμενόμενο χρόνο διάδοσης και δοκιμάστε τον με πιστοποιητικό που είστε πρόθυμοι να ανακαλέσετε. Αν ο κατάλογος δεν μπορεί να ανανεωθεί στον κεντρικό υπολογιστή VPN, η εναλλακτική είναι μικρότερη περίοδος ισχύος συν διαδικασία ανανέωσης που εκτελείται πραγματικά, όχι η υπόθεση ότι η ανάκληση λειτουργεί επειδή υπάρχει ένα URL.
Αποδείξτε την αποδοχή με πραγματικό πελάτη
Συνδέστε έναν πελάτη που θα έπρεπε να επιτρέπεται και επιβεβαιώστε τις διαπραγματευμένες λεπτομέρειες πιστοποιητικού στο αρχείο καταγραφής. Στη συνέχεια δοκιμάστε τις περιπτώσεις που πρέπει να αποτύχουν: πιστοποιητικό πελάτη που παρουσιάζεται ως διακομιστής, πιστοποιητικό από εκδότη εκτός της άγκυρας εμπιστοσύνης και ανακληθέν πιστοποιητικό αν έχετε ένα διαθέσιμο.
Καταγράψτε τον αποδεκτό εκδότη, τον έλεγχο ρόλου και την πηγή ανάκλησης δίπλα στο προφίλ. Αυτή η καταγραφή είναι ό,τι χρειάζεται ο επόμενος μηχανικός όταν μια συσκευή που λειτουργούσε τον περασμένο μήνα σταματήσει να συνδέεται, και είναι επίσης η απόδειξη ότι η εταιρική CA χρησιμοποιείται εντός τεκμηριωμένου ορίου αποδοχής και όχι ως χωματερή εμπιστοσύνης γενικής χρήσης.