Επερχόμενες αλλαγές σχετικά με το TLS Client Authentication στα TLS Server Authentication Πιστοποιητικά

Αγαπητοί Συνδρομητές της HARICA,

Θα θέλαμε να σας ανακοινώνουμε μια επικείμενη αλλαγή που πρόκειται να εφαρμοστεί στα Publicly-Trusted SSL/TLS Web Server Πιστοποιητικά μας.

Συγκεκριμένα, από τις 2 Μαρτίου 2026, η HARICA δεν θα συμπεριλαμβάνει πλέον την τιμή TLS Client Authentication (Client Auth) Extended Key Usage (EKU) από προεπιλογή στα νεοεκδοθέντα πιστοποιητικά TLS Server που συνδέονται με το Chrome Root Store.

Γιατί προχωρούμε σε αυτή την αλλαγή;

Αυτή η αλλαγή επιβάλλεται από την Πολιτική του Google Chrome Root Program. Ενισχύει την ασφάλεια διασφαλίζοντας ότι τα πιστοποιητικά ελέγχου ταυτότητας διακομιστή (server authentication certificates) περιορίζονται αυστηρά στο server authentication.

Πώς σας επηρεάζει αυτό;

Για Standard Web Servers (HTTPS): Δεν υπάρχει καμία επίπτωση. Τα πιστοποιητικά που χρησιμοποιούνται αποκλειστικά για την ασφάλεια ενός ιστότοπου και έχουν εκδοθεί πριν από την ημερομηνία έναρξης ισχύος, θα παραμείνουν έγκυρα και λειτουργικά μέχρι την ημερομηνία λήξης τους.

Για Mutual TLS (mTLS) Παραμετροποιήσεις: Εάν χρησιμοποιείτε επί του παρόντος το ίδιο πιστοποιητικό για την ταυτοποίηση του server σας στους πελάτες (clients) και για την πιστοποίηση του server σας ως πελάτη (client) σε άλλα συστήματα back-end, πρέπει να προβείτε σε ενέργειες.

Απαιτούμενες Ενέργειες: Εάν το σύστημά σας απαιτεί Client Authentication:

• Πρέπει να εκδώσετε ένα αποκλειστικό Client Πιστοποιητικό (S/MIME ή Client Auth) για αυτόν τον συγκεκριμένο σκοπό. Η HARICA προσφέρει τέτοιου είδους πιστοποιητικά.
• Στην περίπτωση που η υποδομή σας δεν υποστηρίζει τη χρήση δύο ξεχωριστών πιστοποιητικών (ένα για Client και ένα για Server Authentication), θα πρέπει να μας υποβάλετε μια αναλυτική περιγραφή της περίπτωσης χρήσης, απαριθμώντας τους λόγους για τους οποίους δεν είναι εφικτή η υιοθέτηση της λύσης των δύο πιστοποιητικών. Η HARICA θα εξετάσει το αίτημά σας και ενδέχεται να χορηγήσει κατ’ εξαίρεση παράταση, ώστε να σας δοθεί ο απαραίτητος χρόνος για την προσαρμογή των συστημάτων σας. Η παράταση δεν μπορεί να υπερβεί τις 15 Μαΐου 2026.
• Με βάση τις βέλτιστες πρακτικές του κλάδου, οι περιπτώσεις χρήσης που βασίζονται σε mTLS θα πρέπει να χρησιμοποιούν Private PKI αντί για πιστοποιητικά Publicly-Trusted. Μπορείτε να επικοινωνήσετε με το τμήμα πωλήσεων στην διεύθυνση sales@harica.gr για περισσότερες πληροφορίες σχετικά με αυτό.

Έχετε επιπλέον ερωτήσεις ή απορίες;

Εάν έχετε ερωτήσεις ή χρειάζεστε περισσότερες πληροφορίες, παρακαλούμε επικοινωνήστε με το τμήμα υποστήριξης της HARICA στο support@harica.gr.

Σημαντική Ανακοίνωση: Κατάργηση του OCSP για τα Publicly-Trusted Πιστοποιητικά TLS της HARICA

Αγαπητοί Συνδρομητές της HARICA,

Από τις 2 Μαρτίου 2026, η HARICA θα καταργήσει επίσημα τη χρήση του πρωτοκόλλου Online Certificate Status Protocol (OCSP) για όλα τα νεοεκδοθέντα publicly-trusted server TLS πιστοποιητικά, με εξαιρέσεις να γίνονται μόνο σε συγκεκριμένες περιπτώσεις, όπου απαιτείται.

Σύμφωνα με τα εξελισσόμενα πρότυπα του κλάδου και τις απαιτήσεις των προγραμμάτων περιήγησης (browsers), τα πιστοποιητικά που εκδίδονται μετά από αυτήν την ημερομηνία δεν θα περιέχουν πλέον, από προεπιλογή, το OCSP responder URL στην επέκταση Authority Information Access (AIA). Αντ’ αυτού, ο έλεγχος ανάκλησης πιστοποιητικών θα γίνεται αποκλειστικά μέσω των Λιστών Ανάκλησης Πιστοποιητικών (Certificate Revocation Lists - CRLs) και των σύγχρονων εγγενών μηχανισμών των browsers.

Γιατί συμβαίνει αυτή η αλλαγή;

Η στροφή ολόκληρου του κλάδου μακριά από το OCSP οφείλεται σε τρεις βασικούς παράγοντες:

1. Ιδιωτικότητα Χρηστών: Τα τυπικά αιτήματα OCSP δεν είναι κρυπτογραφημένα. Όταν ένας browser ελέγχει την κατάσταση ενός πιστοποιητικού μέσω OCSP, ενημερώνει την Αρχή Πιστοποίησης (CA) ποια διεύθυνση IP επισκέπτεται ποιον ιστότοπο. Η κατάργηση του OCSP εξαλείφει αυτή τη διαρροή ιδιωτικότητας, διασφαλίζοντας ότι η HARICA δεν μπορεί να παρακολουθεί τα μοτίβα περιήγησης των χρηστών.

2. Αξιοπιστία και Απόδοση: Οι αναζητήσεις OCSP συχνά προσθέτουν σημαντική καθυστέρηση στο TLS handshake (η λύση “OCSP stapling”, αν και χρήσιμη, δεν εφαρμόζεται καθολικά). Επιπλέον, εάν ένας OCSP responder είναι αργός ή μη προσβάσιμος, μπορεί να προκαλέσει καθυστερήσεις τύπου “soft-fail” ή σφάλματα σύνδεσης “hard-fail”, επηρεάζοντας τη διαθεσιμότητα του ιστότοπου.

3. Σύγχρονα Πρότυπα Ανάκλησης: Browsers όπως οι Apple Safari, Google Chrome και Mozilla Firefox έχουν στραφεί προς πιο αποτελεσματικές μεθόδους ελέγχου ανάκλησης που προστατεύουν την ιδιωτικότητα, όπως τα CRLSets και CRLite. Αυτές οι μέθοδοι βασίζονται στη δημοσίευση συμπιεσμένων CRLs από την CA, αντί για την απάντηση σε μεμονωμένα ερωτήματα OCSP.

Χρονοδιάγραμμα Αλλαγών

• Σήμερα – 1 Μαρτίου 2026: Δεν απαιτείται άμεση ενέργεια. Η HARICA θα συνεχίσει να υποστηρίζει το OCSP για όλα τα ενεργά πιστοποιητικά.
• 2 Μαρτίου 2026: Όλα τα νέα πιστοποιητικά TLS που εκδίδονται από τη HARICA θα παραλείπουν την επέκταση OCSP AIA από προεπιλογή. Ορισμένες εξαιρέσεις θα επιτρέπονται κατά περίπτωση.
• Μετά τις 2 Μαρτίου 2026: Τα υπάρχοντα πιστοποιητικά που εκδόθηκαν πριν από αυτήν την ημερομηνία θα συνεχίσουν να έχουν λειτουργική υποστήριξη OCSP μέχρι τη φυσική τους λήξη. Μέχρι τις 4 Μαΐου 2027, προβλέπεται η πλήρης κατάργηση της δημόσιας υποδομής OCSP για τα πιστοποιητικά TLS.

Πώς θα επηρεάσει στους Συνδρομητές;

Για τη συντριπτική πλειοψηφία των συνδρομητών, δεν απαιτείται καμία ενέργεια. Οι σύγχρονοι web browsers (Chrome, Safari, Firefox και Edge) έχουν ήδη προετοιμαστεί για αυτή τη μετάβαση. Ωστόσο, ένας μικρός αριθμός “legacy” εφαρμογών ή εφαρμογών που δεν είναι browsers, οι οποίες βασίζονται αυστηρά στην παρουσία ενός OCSP URL στο πιστοποιητικό για έλεγχο ανάκλησης τύπου hard-fail, ενδέχεται να αντιμετωπίσουν προβλήματα. Συνιστούμε τα εξής:

• Έλεγχος Legacy Συστημάτων: Εάν χρησιμοποιείτε εξειδικευμένο hardware ή παλαιότερο λογισμικό που απαιτεί OCSP για mutual TLS (mTLS) ή συγκεκριμένους ελέγχους συμμόρφωσης, βεβαιωθείτε ότι υποστηρίζουν ανάκληση βάσει CRL. Εάν χρησιμοποιείτε legacy συστήματα που βασίζονται αποκλειστικά στο OCSP και δεν μπορούν να επεξεργαστούν CRLs, μπορείτε να επικοινωνήσετε με το τμήμα τεχνικής υποστήριξής μας ώστε να συζητήσετε άλλες διαθέσιμες επιλογές.
• OCSP Stapling: Εάν χρησιμοποιείτε επί του παρόντος OCSP Stapling στους web servers σας, ο server απλώς θα σταματήσει να επισυνάπτει απάντηση μόλις εγκατασταθεί το νέο πιστοποιητικό (χωρίς OCSP URL). Αυτό δεν θα διακόψει τη σύνδεση στους σύγχρονους browsers.

Η Δέσμευσή μας για την Ασφάλεια

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

Εφαρμογή Multi-Perspective Issuance Corroboration (MPIC) και Υποχρεωτικών Ελέγχων CAA για Διευθύνσεις Ηλεκτρονικού Ταχυδρομείου

Εφαρμογή Multi-Perspective Issuance Corroboration (MPIC)

Από τις 15 Μαρτίου 2025, η HARICA θα εφαρμόσει το Multi-Perspective Issuance Corroboration (MPIC) για την Εξουσιοδότηση και Έλεγχο των Domain, και τους Ελέγχους Εγγραφών CAA (Certification Authority Authorization) πριν την έκδοση οποιωνδήποτε Πιστοποιητικών TLS για Αυθεντικοποίηση Εξυπηρετητών, σύμφωνα με τα Baseline Requirements for TLS Server Certificates του CA/B Forum.

Με το MPIC, τα αιτήματα DNS για Επικύρωση Domain (Domain Validation) και ελέγχους CAA (CAA Checks) πρέπει να επαληθεύονται από πολλαπλές, τυχαία κατανεμημένες και απομακρυσμένες τοποθεσίες σε όλο το Διαδίκτυο. Εάν η επαλήθευση των πληροφοριών αποτύχει (μέχρι έναν ορισμένο βαθμό), η έκδοση του πιστοποιητικού θα μπλοκαριστεί. Οι κάτοχοι domain πρέπει να διασφαλίσουν ότι οι εξουσιοδοτημένοι DNS server τους είναι προσβάσιμοι από το παγκόσμιο Διαδίκτυο, επιτρέποντας την ολοκλήρωση της επαλήθευσης χωρίς αποτυχίες που θα εμπόδιζαν την έκδοση πιστοποιητικού.

Υπενθυμίζουμε στους συνδρομητές μας ότι τα Δημοσίως Έμπιστα Πιστοποιητικά TLS για Αυθεντικοποίηση Εξυπηρετητών προορίζονται για την αυθεντικοποίηση εξυπηρετητών που είναι προσβάσιμοι μέσω του Διαδικτύου, όπως περιγράφεται στα Baseline Requirements for TLS Server Certificates του CA/Browser Forum.

Υποχρεωτικοί Έλεγχοι CAA για Διευθύνσεις Ηλεκτρονικού Ταχυδρομείου

Επίσης, από τις 15 Μαρτίου 2025, η HARICA θα υποχρεούται να πραγματοποιεί ελέγχους CAA για Διευθύνσεις Ηλεκτρονικού Ταχυδρομείου, όπως απαιτείται από τα Baseline Requirements for the Issuance and Management of Publicly-Trusted S/MIME Certificates του CA/Browser Forum.

Τι Πρέπει να Γνωρίζετε:

• Πριν την έκδοση πιστοποιητικού S/MIME που περιλαμβάνει Διεύθυνση Ηλεκτρονικού Ταχυδρομείου, η HARICA θα ανακτά και θα επεξεργάζεται εγγραφές CAA, παρόμοια με τη διαδικασία που χρησιμοποιείται για τα Πιστοποιητικά TLS.
• Εάν η εγγραφή CAA του DNS σας περιέχει την ετικέτα issuemail, πρέπει να περιλαμβάνει ρητά την τιμή “harica.gr”, εξουσιοδοτώντας την HARICA για την έκδοση πιστοποιητικού S/MIME.
• Εάν δεν υπάρχει ετικέτα issuemail, δεν απαιτείται καμία ενέργεια.

Νέα ιεραρχία έκδοσης Πιστοποιητικών SSL/TLS 2021 της HARICA

Είμαστε στην ευχάριστη θέση να ανακοινώσουμε ότι, την 1η Ιουνίου 2022, η HARICA θα μεταβεί στις Αρχές Πιστοποίησης TLS Root 2021 για την έκδοση πιστοποιητικών SSL/TLS.

Τόσο η HARICA TLS RSA Root CA 2021 όσο και η HARICA TLS ECC Root CA 2021 είναι ήδη προεγκατεστημένες σε λειτουργικά συστήματα Windows καθώς και στο macOS 12 παρέχοντας το απαραίτητο σημείο εμπιστοσύνης (trust anchor) για Google Chrome, Microsoft Edge και άλλα δημοφιλή προγράμματα περιήγησης στο Διαδίκτυο. Επιπλέον, ο Mozilla Firefox έχει ενημερώσει το Certificate Store του με τις νέες RootCA της HARICA.

Για παλαιότερα λειτουργικά συστήματα και προγράμματα περιήγησης, η HARICA εξέδωσε δύο επιπλέον πιστοποιητικά δια-πιστοποίησης (cross-certificates) ώστε να συνδέσει την ιεραρχία της 2021 με την παλαιότερη της 2015 για αυξημένη συμβατότητα.

Τα HARICA TLS Root 2021 ECC και RSA cross-certificates μπορούν να χρησιμοποιηθούν από τους συνδρομητές μας στα αρχεία της αλυσίδας πιστοποιητικών τους, για να καλύψουν την πλειονότητα των προγραμμάτων περιήγησης ανεξάρτητα από την έκδοσή τους.