Γιατί να χρησιμοποιήσετε το CAA;
Οι επιστήμονες υπολογιστών Phillip Hallam-Baker και Rob Stradling ανέπτυξαν το CAA ως απάντηση στις αυξανόμενες ανησυχίες σχετικά με την ασφάλεια των δημοσίως αξιόπιστων αρχών έκδοσης πιστοποιητικών. Αυτή η πρωτοβουλία εμπίπτει στην Task Force του Internet Engineering (IETF), έναν κορυφαίο οργανισμό ανάπτυξης προτύπων (SDO) για το Διαδίκτυο. Το IETF δημιουργεί εθελοντικά πρότυπα που υιοθετούνται ευρέως από χρήστες του Διαδικτύου, χειριστές δικτύων και προμηθευτές εξοπλισμού, επηρεάζοντας την εξέλιξη του Διαδικτύου.
Το IETF τεκμηριώνει τα τεχνικά του πρότυπα σε δημοσιεύσεις γνωστές ως RFC (Αιτήσεις για Σχόλια). Αυτά τα έγγραφα περιγράφουν βασικές πτυχές της υποδομής του Διαδικτύου, συμπεριλαμβανομένων των τεχνολογιών διεύθυνσης, δρομολόγησης και μεταφοράς. Το CAA ορίζεται συγκεκριμένα στο RFC 6844.
Μια αρχή έκδοσης πιστοποιητικών (CA) χρησιμοποιεί πάντα μεθόδους επικύρωση τομέα για να βεβαιωθείτε ότι κάθε SSL /TLS Το αίτημα πιστοποιητικού έχει εγκριθεί (συνήθως διασφαλίζοντας ότι συνδέεται κατά κάποιο τρόπο με έναν συγκεκριμένο ιστότοπο που χρησιμοποιεί αυτόν τον τομέα).
Για παράδειγμα, μια ΑΠ ενδέχεται να παρέχει ένα ειδικό αρχείο επαλήθευσης στον αιτούντα. Η τοποθέτηση αυτού του αρχείου στον ιστότοπο αποδεικνύει ότι ο αιτών ελέγχει επίσης αυτόν τον ιστότοπο, αλλά δεν μπορεί να εγγυηθεί το νομιμότητα αυτού του ελέγχου. Ένας χάκερ που αποκτά τον έλεγχο ενός ιστότοπου ενδέχεται να μεταμφιέζεται ως ο νόμιμος κάτοχος και, στη συνέχεια, θα μπορούσε να ζητήσει και να λάβει ένα SSL /TLS πιστοποιητικό που περνά τους τυπικούς ελέγχους της ΚΑ και ως εκ τούτου φαίνεται νόμιμος. Θα μπορούσαν τότε να γυρίσουν και να χρησιμοποιήσουν αυτό το SSL /TLS πιστοποιητικό για αναταραχή, σε αυτόν τον ιστότοπο ή αλλού.
Το CAA συμβάλλει στον αποκλεισμό αυτού του είδους εκμετάλλευσης, ορίζοντας ποιες ΑΠ επιτρέπεται να εκδίδουν πιστοποιητικά για έναν τομέα (ή ακόμη και τον περιορισμό της έκδοσης πιστοποιητικών συνολικά). Αυτό περιορίζει τη ζημιά που μπορεί να προκαλέσει ένας αεροπειρατής - ακόμη και αν έχουν τον έλεγχο ενός ιστότοπου, θα έχουν δραστικά λιγότερες επιλογές για να σκοράρουν ένα κακόβουλο SSL /TLS πιστοποιητικό.
Τι είναι το CNAME;
Μια εγγραφή CNAME είναι ένας τύπος διαμόρφωσης DNS που επιτρέπει έναν τομέα, όπως π.χ store.mybusiness.com, να λειτουργεί ως ψευδώνυμο για άλλον, όπως mybusiness.com. Αντί να διαχειρίζεται πολλές εγγραφές A για να αντικατοπτρίζει τις αλλαγές διεύθυνσης IP, ένα CNAME το απλοποιεί δείχνοντας το ψευδώνυμο στον τομέα προορισμού. Αυτή η προσέγγιση είναι εξαιρετικά επωφελής για επιχειρήσεις που αλλάζουν τακτικά κεντρικούς υπολογιστές ιστού ή παρόχους CDN. Επιπλέον, οι εγγραφές CNAME είναι ανεκτίμητες για τη δημιουργία συστημάτων ανακατεύθυνσης, όπου η κίνηση κατευθύνεται από έναν κύριο διακομιστή σε έναν δευτερεύοντα, διασφαλίζοντας τη συνέχεια της υπηρεσίας κατά τη διάρκεια διακοπών.
Στο πλαίσιο της εξουσιοδότησης αρχής έκδοσης πιστοποιητικών (CAA), οι εγγραφές CNAME επηρεάζουν τη διαδικασία ανακατευθύνοντας τους ελέγχους CAA στον τομέα προορισμού. Για παράδειγμα, εάν shop.mysite.net χρησιμοποιεί ένα CNAME για να δείξει mysite.net, μια ΑΠ που πραγματοποιεί έλεγχο CAA θα αξιολογήσει τις εγγραφές για mysite.net για την επαλήθευση της εξουσιοδότησης για την έκδοση πιστοποιητικού. Εάν η εγγραφή της ΥΠΑ είναι ενεργοποιημένη mysite.net δεν εξουσιοδοτεί την ΑΠ, το πιστοποιητικό δεν μπορεί να εκδοθεί. Αυτό διασφαλίζει τη συνεπή επιβολή των πολιτικών CAA ακόμη και όταν οι τομείς αξιοποιούν τις εγγραφές CNAME για ψευδώνυμο DNS.
Πώς λειτουργεί το CAA
Η CAA χρησιμοποιεί DNS
The Σύστημα ονομάτων τομέα (DNS) είναι ένα κρίσιμο μέρος της υποδομής του Διαδικτύου. Ο κάτοχος οποιουδήποτε τομέα διατηρεί εγγραφές DNS (εντός των λεγόμενων αρχεία ζώνης) δείχνοντας το όνομα τομέα τους στη διεύθυνση IP όπου φιλοξενείται ο ιστότοπός τους και ας πληκτρολογήσουμε google.com σε ένα παράθυρο του προγράμματος περιήγησης αντί 216.58.194.46.
Οι εγγραφές DNS χρησιμοποιούνται συνήθως ως "τηλεφωνικός κατάλογος για το Διαδίκτυο", αλλά το DNS επιτρέπει επίσης άλλους τύπους ειδικών εγγραφών που μπορούν να εκχωρήσουν άλλες πληροφορίες σε ένα όνομα τομέα.
Εγγραφές CAA
Η CAA χρησιμοποιεί ένα ειδικό είδος δίσκου που ονομάζεται a Αρχείο πόρων εξουσιοδότησης αρχής πιστοποίησης (Εγγραφή CAA). Αυτά δημοσιεύονται χρησιμοποιώντας το DNS και ο κάτοχος του τομέα προσθέτει απλώς εγγραφές CAA μαζί με τις άλλες εγγραφές του DNS. Μια εγγραφή CAA περιλαμβάνει ένα ετικέτα και σε έναν αξίακαι το ζεύγος τιμής-τιμής αναφέρεται ως περιουσία. Υπάρχει επίσης ένα σημαία υποδεικνύοντας πόσο κρίσιμη είναι αυτή η ιδιότητα. Δείτε πώς φαίνεται:
example.com. Έκδοση CAA 0 "ssl.com"
Εδώ, example.com είναι ο τομέας στον οποίο ισχύει αυτή η εγγραφή και η CAA μας ενημερώνει για το είδος της εγγραφής. ο 0 είναι η σημαία (το μηδέν είναι η προεπιλογή). Η ετικέτα είναι ζήτημα και η τιμή (σε εισαγωγικά) είναι ssl.com, που αποτελούν μαζί το ακίνητο.
Σημαίες
Οι σημαίες έχουν μόνο δύο αυστηρά καθορισμένες καταστάσεις αυτήν τη στιγμή: 0 (μη κριτική) και 1 (κρίσιμος). Μια κριτική σημαία λέει στην ΑΑ ότι αυτό πρέπει κατανοήστε πλήρως την ετικέτα ιδιότητας για να προχωρήσετε. Το RFC 6844 αφήνει ανοιχτές άλλες δυνατότητες για χρήση σημαίας που ορίζει ο χρήστης (περισσότερα για αυτό παρακάτω).
Ετικέτες
Το RFC 6844 ορίζει τη χρήση τριών κοινών ετικετών: ζήτημα, έκδοση και ιωδιού. (Όπως με τις σημαίες, επιτρέπει άλλους πιθανούς προσαρμοσμένους τύπους ετικετών.)
The ζήτημα ετικέτα
The ζήτημα Η ετικέτα καθορίζει ποια (εάν υπάρχει) αρχή εξουσιοδότησης για την έκδοση πιστοποιητικών για αυτόν τον τομέα. Για παράδειγμα, ο κάτοχος του τομέα example.com μπορεί να περιορίσει την έκδοση πιστοποιητικών σε μία ΑΠ (εδώ, SSL.com) χρησιμοποιώντας το ακόλουθο αρχείο ζώνης DNS:
example.com. Έκδοση CAA 0 "ssl.com"
Ένας κάτοχος τομέα μπορεί να επιλέξει να ρυθμίσει πολλά αρχεία ζώνης για έναν τομέα:
example.com. Έκδοση CAA 0 "ssl.com" example.com. Έκδοση CAA 0 "comodoca.com"
Οι παραπάνω εγγραφές περιορίζουν SSL /TLS έκδοση πιστοποιητικού για example.com σε δύο CA (SSL.com και Comodo.com).
The ζήτημα Η εγγραφή επιτρέπει επίσης στο όνομα CA να εκδίδει πιστοποιητικά για οποιονδήποτε υποτομέα του καθορισμένου τομέα. Ένα αρχείο που επιτρέπει το SSL.com μπορεί έτσι να επιτρέπει την έκδοση πιστοποιητικών για example.com και υποτομείς όπως www.example.com, mail.example.com και ακόμη και τον ειδικό υποτομέα μπαλαντέρ * .example.com.
Μια εγγραφή CAA μπορεί να χρησιμοποιηθεί για περιορίζω έκδοση πιστοποιητικού, επίσης - αυτή η εγγραφή ενημερώνει τις αρχές έκδοσης πιστοποιητικών που χρησιμοποιούν το CAA Όχι. SSL /TLS πιστοποιητικά θα πρέπει να εκδοθούν για example.com και υποτομείς από κάθε ΑΑ:
example.com. Πρόβλημα CAA 0 ";"
(Το ερωτηματικό σε αυτό το παράδειγμα σημαίνει «μην επιτρέπετε τίποτα εδώ", Αλλά όπως θα δείξουμε αργότερα χρησιμοποιείται επίσης για τον καθορισμό προσαρμοσμένων παραμέτρων."
Λάβετε υπόψη ότι μια τυπική ετικέτα έκδοσης επιτρέπει στην ΑΠ να εκδίδει πιστοποιητικό για χαρακτήρες μπαλαντέρ εκτός εάν τροποποιηθεί από…
The έκδοση ετικέτα
Αυτή η ετικέτα καθορίζει ότι μια ΑΠ έχει εξουσιοδότηση να εκδίδει πιστοποιητικά μπαλαντέρ για τον τομέα του κατόχου (π.χ. * .example.com).
Οι χαρακτήρες μπαλαντέρ μπορούν να αντιπροσωπεύουν ένα απεριόριστο σύνολο υποτομέων, και επομένως απαιτείται ιδιαίτερη προσοχή και προσοχή κατά την έκδοση πιστοποιητικών χαρακτήρων μπαλαντέρ. Ο έκδοση Η ετικέτα επιτρέπει στον κάτοχο του τομέα να καθορίσει ποιες ΑΠ μπορούν να εκδίδουν πιστοποιητικά για χαρακτήρες μπαλαντέρ ξεχωριστά από τον κύριο τομέα ή άλλους υποτομείς. έκδοση Οι ετικέτες έχουν προτεραιότητα έναντι οποιουδήποτε άλλου ζήτημα ετικέτες. Χρησιμοποιούν την ίδια σύνταξη με το ζήτημα ετικέτα. Μερικά παραδείγματα:
example.com. Έκδοση CAA 0 "ssl.com" example.com. CAA 0 Issuewild ";"
Τα παραπάνω επιτρέπουν στο SSL.com να εκδίδει πιστοποιητικά για example.com και όλους τους υποτομείς εκτός για το μπαλαντέρ * .example.com. (Ούτε το SSL.com ούτε οποιαδήποτε άλλη ΑΠ επιτρέπεται να εκδίδουν πιστοποιητικά μπαλαντέρ για example.com.)
example.com. Πρόβλημα CAA 0 ";" example.com. CAA 0 Issuewild "ssl.com"
Αυτό το παράδειγμα απαγορεύει όλοι Αρχές έκδοσης πιστοποιητικών προς example.com και τους υποτομείς του, αλλά δημιουργεί μια εξαίρεση που επιτρέπει στο SSL.com να εκδίδει πιστοποιητικά μπαλαντέρ (και αποκλειστικά πιστοποιητικά μπαλαντέρ) για example.com.
The ιωδιού ετικέτα
Η τρίτη καθορισμένη ετικέτα είναι ιωδιού. Αυτή η ετικέτα μπορεί να χρησιμοποιηθεί για την αναφορά μη έγκυρων αιτημάτων πιστοποιητικού στον κάτοχο του τομέα και μοιάζουν με αυτό:
example.com. CAA 0 iodef "mailto: certissues@example.com" example.com. CAA 0 iodef "certissues.example.com"
Η κορυφαία εγγραφή παρέχει τις πληροφορίες CA που απαιτούνται για την αποστολή ειδοποίησης μέσω email στη διεύθυνση certissues@example.com. Ο δεύτερος κατευθύνει την ΑΠ να δημοσιεύσει ένα μήνυμα συμβάντος σε μια υπηρεσία ιστού (που έχει ρυθμιστεί για αυτόν τον σκοπό από τον κάτοχο του τομέα) στη διεύθυνση certissues.example.com. (Μπορούν να χρησιμοποιηθούν μία ή και οι δύο μέθοδοι, ανάλογα με τον τρόπο με τον οποίο η ΑΠ και ο κάτοχος τομέα έχουν ρυθμίσει τις λειτουργίες τους.)
ιωδιού μετά τα μηνύματα χρησιμοποιούν μια τυπική μορφή που ονομάζεται Αντικείμενο συμβάντος Περιγραφή ανταλλαγής μορφής ή IODEF - εξ ου και το όνομα. (Το IODEF ορίζεται σε RFC 6546.)
Η ετικέτα έκδοσης email για S/MIME
Μια σημαντική εξέλιξη στην ΥΠΑ είναι η επέκταση σε S/MIME Πιστοποιητικά (Secure/Multipurpose Internet Mail Extensions), επισημοποιημένα στο RFC 9495. S/MIME Τα πιστοποιητικά παρέχουν ασφάλεια ηλεκτρονικού ταχυδρομείου μέσω του ελέγχου ταυτότητας, του απορρήτου των δεδομένων και της ακεραιότητας των μηνυμάτων. Το φόρουμ CA/Browser έχει εισαγάγει μια νέα ετικέτα ιδιοκτησίας CAA που ονομάζεται "issuemail" ειδικά για τον έλεγχο της έκδοσης S/MIME πιστοποιητικά.
Από τις 15 Σεπτεμβρίου 2024, συνιστάται στις ΑΠ να εφαρμόζουν τον έλεγχο CAA S/MIME πιστοποιητικά, με υποχρεωτική εφαρμογή έως τις 15 Μαρτίου 2025. Η τυπική φόρμα εγγραφής CAA για τις διευθύνσεις ηλεκτρονικού ταχυδρομείου θα έχει την εξής μορφή:
mail.client.example ΥΠΑ 0 issuemail "authority.example"
Αυτή η επέκταση του CAA στα πιστοποιητικά ηλεκτρονικού ταχυδρομείου παρέχει στους κατόχους τομέα το ίδιο επίπεδο ελέγχου S/MIME έκδοση πιστοποιητικού όπως έχουν για TLS πιστοποιητικών, μειώνοντας τον κίνδυνο μη εξουσιοδοτημένης έκδοσης πιστοποιητικών.
Σημαίες και ετικέτες που καθορίζονται από ΑΠ
Το CAA όπως περιγράφεται στο RFC 6844 ορίζει συγκεκριμένα μόνο δύο καταστάσεις σημαίας (0 και 1) και τρεις ετικέτες (ζήτημα, έκδοση και ιωδιού). Ωστόσο, αφήνει το σχέδιο αρκετά ανοιχτό ώστε οι ΑΠ να δημιουργούν και να χρησιμοποιούν προσαρμοσμένες ετικέτες και σημαίες για τον καθορισμό της διαδικασίας έκδοσης πιστοποιητικών. Παραδείγματα μπορεί να είναι:
example.com. Πρόβλημα CAA 0 "SSL.com; policy = ev"
Αυτή η εγγραφή χρησιμοποιεί ένα πρότυπο ζήτημα ετικέτα με μια επιπλέον παράμετρο που καθοδηγεί την ΑΠ να χρησιμοποιεί την πολιτική εκτεταμένης επικύρωσης (EV) κατά την έκδοση πιστοποιητικού για αυτόν τον τομέα.
example.com. CAA 128 pca "PCA = 12345"
Ο κάτοχος τομέα θα μπορούσε να χρησιμοποιήσει αυτήν την εγγραφή με ένα νέο, καθορισμένο από την ΑΠ pca για να δείξει ότι έχουν έναν προτιμώμενο λογαριασμό πελάτη και ορίζει τον αριθμό λογαριασμού ως παράμετρο. (Η σημαία μπορεί να είναι και μια προσαρμοσμένη τιμή έως και 255.) Ανάλογα με τον τρόπο με τον οποίο η ΑΑ ρυθμίζει τον λογαριασμό, αυτό θα μπορούσε να επιτρέψει συγκεκριμένες μεθόδους χρέωσης, επιπλέον επαλήθευση που καθορίζεται από λογαριασμό ή άλλο ειδικό χειρισμό.
Υπέρ και κατά
Υπάρχουν αρκετοί εξαιρετικοί λόγοι για να χρησιμοποιήσετε CAA. Το κύριο και σημαντικότερο πλεονέκτημα είναι η ικανότητα της ΥΠΑ να μειώνει σημαντικά τον κίνδυνο λανθασμένης έκδοσης πιστοποιητικού. Αυτό βοηθά στην προστασία του τομέα σας, της επιχείρησής σας και της διαδικτυακής σας ταυτότητας. Πιθανοί εισβολείς που μπορεί να έχουν βρει ένα σφάλμα στο λογισμικό μιας συγκεκριμένης CA δεν μπορούν να το εκμεταλλευτούν για να εκδώσουν πιστοποιητικά SSL για τον τομέα σας. Επιπλέον, η χρήση της ετικέτας iodef σάς επιτρέπει να λάβετε μια αναφορά εάν επιχειρήσετε μια εκμετάλλευση.
Ο σχεδιασμός της CAA αυξάνει την ασφάλεια, αλλά μπορεί επίσης να επιτρέψει πιο λεπτομερή κατανομή πόρων - για παράδειγμα, μια εταιρεία θα μπορούσε να δημιουργήσει αρχεία για να επιτρέψει (ή να περιορίσει) το τμήμα πωλήσεων και μάρκετινγκ να αγοράσει πιστοποιητικά SSL για το sales.example.com από μια καθορισμένη πηγή.
Επιπλέον, το CAA προσφέρει μεγάλη ευελιξία. Για έναν κάτοχο τομέα, χρησιμοποιεί εγγραφές πόρων DNS που βρίσκονται υπό τον δικό τους έλεγχο και μπορούν να αλλάξουν ανάλογα με τις ανάγκες, έτσι δεν συνδέονται με μια συγκεκριμένη ΑΠ (και μπορούν να έχουν περισσότερες από μία ΑΠ εξουσιοδοτημένες με εγγραφές ζητημάτων για οποιοδήποτε συγκεκριμένο όνομα τομέα) . Για CA, ακόμη και εκτός από προσαρμοσμένες χρήσεις, οι κανόνες που θεσπίστηκαν πρόσφατα από το CA / B Forum (η ομάδα που ορίζει πρότυπα για θέματα ασφαλείας CA και προγράμματος περιήγησης) μπορούν να επιτρέψουν τη χρήση εγγραφών CAA για σκοπούς επικύρωσης, παρέχοντας έναν άλλο καλό λόγο να τις χρησιμοποιήσουμε.
Ένα μειονέκτημα είναι ότι ακόμη και όταν υπάρχουν εγγραφές CAA, ο χρήστης δεν μπορεί επιβάλλω η χρήση του από αρχή έκδοσης πιστοποιητικών. Μια ΑΠ πρέπει να συμμορφώνεται με το RFC 6844 για την εκτέλεση αυτών των εγγραφών και μια μη συμμορφούμενη ΑΠ μπορεί απλώς να αγνοήσει τις ρητές επιθυμίες του κατόχου τομέα, όπως δηλώνεται στις εγγραφές CAA.
Το CAA πρέπει επίσης να ρυθμιστεί σωστά τόσο από τον κάτοχο του τομέα όσο και από ένα CA. Ας κρυπτογραφήσουμε (το οποίο υποστηρίζει CAA) πρόσφατα ανέφεραν ένα μικρό πρόβλημα με τη βάση κώδικα που δυστυχώς οδήγησε στην παράβλεψη των κανόνων της CAA και στην κακή έκδοση έξι πιστοποιητικών. Κανένα από αυτά δεν ήταν κακόβουλες εξαιρέσεις (και kudos στην ομάδα Let's Encrypt για επίλυση και αναφορά του ζητήματος εντός ωρών από την ανακάλυψή τους). Ωστόσο, αυτό τονίζει ότι μια συμμορφούμενη αρχή έκδοσης πιστοποιητικών πρέπει εφαρμόστε το CAA άψογα.
Ένα άλλο πιθανό ζήτημα είναι η εξάρτηση της CAA στο DNS. Εκτός αν ένας κάτοχος τομέα ασφαλίσει τις υπηρεσίες ονομάτων τους, αυτό μπορεί να είναι ένας φορέας επίθεσης. Το RFC 6844 προτείνει εφαρμογή Επεκτάσεις ασφάλειας συστήματος ονόματος τομέα (DNSSEC), που χρησιμοποιεί ψηφιακά υπογεγραμμένες εγγραφές DNS για έλεγχο ταυτότητας δεδομένων και καταπολέμηση της απειλής της πλαστογράφησης DNS.
Τέλος, ακόμη και με την εφαρμογή CAA και τη σωστή εφαρμογή, μια εγγραφή CAA από μόνη της δεν μπορεί να αποτρέψει εντελώς την έκδοση πιστοποιητικών απατεώνων. Παρόλο που το CAA είναι ένα χρήσιμο και σημαντικό εργαλείο για τον περιορισμό των επιλογών ενός εισβολέα, ένας αεροπειρατής με επαρκή πρόσβαση (για παράδειγμα, ελέγχοντας το DNS ή μέσω της κοινωνικής μηχανικής) μπορεί να είναι σε θέση να το δρομολογήσει.
Συμπέρασμα
Η εξουσιοδότηση της αρχής πιστοποίησης έχει τρομερές δυνατότητες ως μέρος ενός ευρύτερου οικοσυστήματος ασφάλειας και η ευρεία υιοθέτηση και εφαρμογή της CAA θα προστατεύει από την εσφαλμένη έκδοση πιστοποιητικών. Αν και η CAA από μόνη της δεν θα σταματήσει κάθε λάθος έκδοση πιστοποιητικού, είναι ένα καλό βήμα προς τη σωστή κατεύθυνση και το SSL.com θα ήθελε να σας παροτρύνει να εξετάσετε το ενδεχόμενο να χρησιμοποιήσετε μόνοι σας τις εγγραφές CAA.
Αναφορές
- RFC6844: Εγγραφή πόρων εξουσιοδότησης αρχής πιστοποίησης DNS (CAA)
- RFC5070: Η μορφή ανταλλαγής περιγραφής αντικειμένου περιστατικού
- RFC6546: Μεταφορά μηνυμάτων Διαδικτύου Άμυνας σε πραγματικό χρόνο (RID) μέσω HTTP /TLS
- RFC4033: Εισαγωγή και απαιτήσεις ασφάλειας DNS
- CA / B Forum Ballot 125 - Εγγραφές CAA
- Καταχώριση Wikipedia σχετικά με την Εξουσιοδότηση αρχής πιστοποίησης DNS
Σχετικοί Οδηγοί
- Ποιες είναι οι απαιτήσεις για SSL.com SSL /TLS Επικύρωση τομέα πιστοποιητικού;
- Ποια είναι η "Μοναδική αξία" που χρησιμοποιείται στην επικύρωση τομέα (DV);
- Όνομα τομέα SSL /TLS Προ-επικύρωση
