PKCS12, PEM ή DER: τι χρειάζεται πραγματικά ένας πελάτης VPN

Στις συζητήσεις για πιστοποιητικά κυκλοφορούν δύο ισχυρισμοί. Ο πρώτος είναι ότι ένα .p12 είναι η ισχυρή επιλογή και ένα .pem η χαλαρή· ο δεύτερος ότι ένα αρχείο κειμένου πρέπει να είναι ασφαλές για αποστολή επειδή μπορείτε να το διαβάσετε. Κανένας δεν αντέχει ένα λεπτό ελέγχου.

Τα PKCS12, PEM και DER περιγράφουν πώς τα αντικείμενα πιστοποιητικού συσκευάζονται και κωδικοποιούνται. Δεν αποφασίζουν ποιος είναι ο ομότιμος, αν ο εκδότης είναι αξιόπιστος ή αν το αρχείο χρειάζεται κωδικό.

Το τι δέχεται ο πελάτης είναι ζήτημα συμβατότητας. Το τι περιέχει το αρχείο είναι ζήτημα ταυτότητας. Κρατήστε τα χωριστά και τα περισσότερα σφάλματα εισαγωγής παύουν να είναι μυστηριώδη.

Τρία δοχεία, ένα μοντέλο αντικειμένου

Ξεκινήστε από αυτό που έχετε πραγματικά. Ένα πιστοποιητικό είναι μια υπογεγραμμένη δήλωση για ένα δημόσιο κλειδί. Το ιδιωτικό κλειδί είναι ξεχωριστό υλικό που αποδεικνύει ότι ελέγχετε αυτό το κλειδί. Μια αλυσίδα είναι το σύνολο των εκδοτών που συνδέουν το πιστοποιητικό σας με μια ρίζα που εμπιστεύεται ο πελάτης. Και τα τρία υπάρχουν ανεξάρτητα από τη συσκευασία.

Ένα αρχείο PKCS12, συνήθως .p12 ή .pfx, είναι δοχείο που ορίζεται στο RFC 7292 και μπορεί να μεταφέρει ιδιωτικό κλειδί, ένα ή περισσότερα πιστοποιητικά και την αλυσίδα σε ένα μπλοκ προστατευμένο με κωδικό, με ψευδώνυμο που ονομάζει την ταυτότητα. Ένα αρχείο PEM είναι πλαίσιο κειμένου κατά RFC 7468: σώμα base64 μεταξύ γραμμών BEGIN και END, και ένα αρχείο μπορεί να κρατά πολλά μπλοκ στη σειρά. Το DER είναι η δυαδική κωδικοποίηση των ίδιων δομών ASN.1, και το σώμα PEM είναι κυριολεκτικά DER τυλιγμένο σε base64.

Η τελευταία πρόταση αξίζει να μείνει. Η μετατροπή PEM σε DER ξαναγράφει το πλαίσιο, όχι το περιεχόμενο, και η αντίστροφη επιστρέφει τα αρχικά byte.

Η κωδικοποίηση δεν είναι κρυπτογράφηση

Το base64 είναι αλφάβητο μεταφοράς. Δεν κρύβει τίποτα και οποιοσδήποτε μπορεί να αποκωδικοποιήσει ένα μπλοκ PEM σε ένα κέλυφος. Ένα αρχείο DER είναι δυαδικό και εξίσου δημόσιο. Καμία από τις δύο ιδιότητες δεν είναι προστασία και καμία δεν υπονοεί ότι υπάρχει κωδικός.

Η πραγματική προστασία βρίσκεται στο υλικό κλειδιού. Ένα πακέτο PKCS12 μπορεί να κρυπτογραφήσει το περιεχόμενό του με κλειδί που παράγεται από κωδικό. Ένα ιδιωτικό κλειδί PEM μπορεί να κρυπτογραφηθεί με παλιό μπλοκ κεφαλίδας ή να κρατηθεί σε PKCS#8 EncryptedPrivateKeyInfo. Ένα πιστοποιητικό μόνο του δεν κρατά τίποτα μυστικό, γι' αυτό μια εξαγωγή που έδωσε μόνο πιστοποιητικό αφήνει τον πελάτη ανίκανο να ταυτοποιηθεί, σε όποια μορφή κι αν το τυλίξετε.

Η επέκταση είναι υπόδειξη, όχι σύμβαση. Αρχεία που τελειώνουν σε .cer και .crt εμφανίζονται και στις δύο κωδικοποιήσεις, και οι συσκευές εξάγουν πιστοποιητικά DER με ονόματα .pem αρκετά συχνά ώστε η εικασία από την κατάληξη να κοστίζει ένα απόγευμα. Διαβάστε τα πρώτα byte αντί γι' αυτό: ένα αρχείο PEM ανοίγει με γραμμή BEGIN, ενώ το DER αρχίζει με 0x30 επειδή η εξωτερική δομή είναι SEQUENCE.

Γιατί αποτυγχάνει πραγματικά η εισαγωγή

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

Οι παράμετροι κρυπτογράφησης προκαλούν ένα τέταρτο, και μοιάζει ακριβώς με λάθος κωδικό. Παλαιότερες συσκευές εξήγαγαν αρχεία PKCS12 με RC2-40 και 3DES, που το OpenSSL 3 απορρίπτει εκτός αν φορτωθεί ο legacy πάροχος. Η επανεξαγωγή από τη συσκευή με AES-256-CBC και PBKDF2 είναι η διαρκής λύση. Το να μένουν παλιοί κρυπταλγόριθμοι μόνιμα ενεργοί σε μηχάνημα πελάτη για χάρη ενός αρχείου είναι κακή ανταλλαγή.

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

Ελέγξτε πριν μετατρέψετε

Διαβάστε τη δομή χωρίς να εκτυπώνετε μυστικά. Το openssl pkcs12 -in bundle.p12 -info -noout αναφέρει τους αλγορίθμους κρυπτογράφησης και τα ψευδώνυμα καταστέλλοντας την έξοδο κλειδιού και πιστοποιητικού, και το εγχειρίδιο openssl-pkcs12 τεκμηριώνει τις σημαίες. Το να αφαιρέσετε το -noout και να προσθέσετε το -nodes είναι για αρχεία που σκοπεύετε να κρατήσετε, όχι για μια γρήγορη ματιά, γιατί γράφει το ιδιωτικό κλειδί σε καθαρή μορφή.

Για ένα πιστοποιητικό, το openssl x509 -in cert.pem -noout -subject -issuer -dates απαντά ό,τι δεν θα απαντήσει ένας διάλογος εισαγωγής, και προσθέτοντας το -ext subjectAltName δείχνει τα ονόματα για τα οποία το πιστοποιητικό ισχύει πραγματικά. Αν το αρχείο είναι DER, προσθέστε το -inform DER· αυτή η μία σημαία λύνει τα περισσότερα σφάλματα unable-to-load.

Το ταίριασμα κλειδιού με πιστοποιητικό είναι μηχανικό και αξίζει πριν από κάθε εισαγωγή:

openssl x509 -in cert.pem -noout -pubkey | openssl sha256
openssl pkey -in key.pem -pubout | openssl sha256

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

Τι δεν αλλάζει ποτέ η μορφή

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

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

Μια σειρά που αποφεύγει επανάληψη

Ρωτήστε την τεκμηρίωση του πελάτη ποιες κωδικοποιήσεις δέχεται και ποιο δοχείο περιμένει για ταυτότητα πελάτη, και μετά δείτε τι σας έδωσαν. Αν ο πελάτης θέλει μία εισάξιμη ταυτότητα και έχετε χωριστά αρχεία PEM, φτιάξτε το πακέτο μία φορά με κωδικό που ελέγχετε και κρατήστε τις πηγές. Αν θέλει PEM, εξαγάγετε το κλειδί και την αλυσίδα, και μετά αφαιρέστε τα ενδιάμεσα αρχεία μέσω της διαδικασίας διαχείρισης διαπιστευτηρίων που ήδη χρησιμοποιεί η ομάδα σας.

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