1. Στόχος

Ένα server certificate που πλησιάζει στη λήξη αντικαθίσταται από νέο· αξιολογούνται η επαναχρησιμοποίηση key και ένας νέος serial number.

Το έγγραφο συμπληρώνει το κύριο README με τεχνικό πλαίσιο, ερωτήσεις review και λειτουργικές παραμέτρους. Δεν είναι εγχειρίδιο λειτουργίας δημόσιας CA· αποτελεί αναπαραγώγιμο παράδειγμα μάθησης και ανάλυσης.

2. Τι γίνεται

Το παράδειγμα εκτελείται τοπικά, δημιουργεί προσωρινά artifacts μόνο κάτω από το work/ και γράφει evidence κάτω από το work/evidence/. Ανάλογα με το θέμα, δημιουργεί root CA, intermediate CA, CSR, server certificate, client certificate, CRL, γεγονός revocation ή μοντέλο αυτοματοποίησης.

Τα βήματα είναι σκόπιμα μικρά:

1. Διαβάστε τα configuration files.
2. Εκτελέστε το script.
3. Εξετάστε το evidence.
4. Ερμηνεύστε την έξοδο του OpenSSL.
5. Συζητήστε την αστοχία ή το λειτουργικό ερώτημα.
6. Επιβεβαιώστε το cleanup και την προστασία των private keys.

3. Γιατί γίνεται

Οι αστοχίες PKI σπάνια είναι απλώς συντακτικά σφάλματα. Ένα certificate μπορεί να δημιουργηθεί τεχνικά αλλά να είναι λανθασμένο: λάθος issuer, λάθος SAN, υπερβολική διάρκεια ισχύος, απουσία key usage, ασαφής chain, απουσία μοντέλου revocation ή εκτεθειμένο private key. Γι’ αυτό το παράδειγμα συνδέει κάθε τεχνική ενέργεια με δομή review.

4. Τυπικές εντολές

openssl version
openssl req -in work/csr/server.csr.pem -noout -subject -text 2>/dev/null || true
openssl x509 -in work/certs/server.crt.pem -noout -subject -issuer -serial -dates 2>/dev/null || true
openssl x509 -in work/certs/server.crt.pem -noout -text 2>/dev/null | sed -n '/X509v3 extensions:/,/Signature Algorithm/p' || true
openssl verify -CAfile work/root/certs/root.crt.pem -untrusted work/intermediate/certs/intermediate.crt.pem work/certs/server.crt.pem 2>/dev/null || true
find work/evidence -type f -maxdepth 2 -print 2>/dev/null | sort || true

5. Έλεγχος επιτυχίας

• Το script τερματίζει χωρίς απροσδόκητο σφάλμα.
• Τα αρχεία evidence αντιστοιχούν στο θέμα του παραδείγματος.
• Τα end-entity certificates έχουν CA:FALSE.
• Τα CA certificates έχουν CA:TRUE και κατάλληλο key usage.
• Τα server certificates περιέχουν SANs.
• Η επαλήθευση της chain χρησιμοποιεί χωριστά τη root CA ως trust anchor και την intermediate CA ως untrusted chain certificate.
• Δεν διατυπώνονται ισχυρισμοί για συμπεριφορά revocation, OCSP ή CRL χωρίς evidence ή σαφές όριο του lab.

6. Συνηθισμένα λάθη

7. Ζητήματα ασφάλειας

Οι πραγματικές PKIs πρέπει να προστατεύουν τα root και intermediate keys ισχυρότερα από αυτό το lab. Τα root keys συνήθως φυλάσσονται offline. Τα intermediate keys προστατεύονται με HSMs, αυστηρά file permissions, audit logs και διαχωρισμένους ρόλους. Τα δημόσια έμπιστα certificates υπόκεινται σε πρόσθετες απαιτήσεις, τις οποίες το workshop μπορεί να εξηγήσει αλλά δεν προσομοιώνει.

8. Ρεαλιστική χρήση

Το μοτίβο εφαρμόζεται σε εσωτερικά TLS certificates, mTLS μεταξύ services, Kubernetes Ingress, Vault PKI, cert-manager, Smallstep, SPIFFE/SPIRE και παραδοσιακές εταιρικές PKIs. Καθοριστικό δεν είναι το εργαλείο αλλά το evidence: ποιος υπογράφει, για ποιο σκοπό ισχύει το certificate, πώς διανέμεται η εμπιστοσύνη, πότε αρχίζει το renewal και πώς αντιμετωπίζεται το revocation.

9. Ροή workshop

1. Διαβάστε τον στόχο δυνατά και ορίστε το πεδίο εφαρμογής.
2. Διαχωρίστε τα αρχεία του workshop από τα runtime artifacts.
3. Ανοίξτε το OpenSSL configuration και σημειώστε τα σχετικά sections.
4. Εντοπίστε τα paths των private keys.
5. Ελέγξτε το CSR subject και τα SANs.
6. Εξηγήστε τα CA extensions πριν από την υπογραφή.
7. Δημιουργήστε το certificate ή ελέγξτε το model artifact.
8. Συγκρίνετε issuer και subject.
9. Ερμηνεύστε τα basic constraints και το key usage.
10. Εκτελέστε επαλήθευση της chain.
11. Αναπαράγετε σκόπιμα την αστοχία, αν το παράδειγμα περιλαμβάνει κάποια.
12. Ανοίξτε τα αρχεία evidence και ελέγξτε ότι δεν περιέχουν private keys.
13. Θέστε το λειτουργικό ερώτημα: ποιος είναι υπεύθυνος για αυτό το certificate;
14. Θέστε το ερώτημα ασφάλειας: πώς θα ανιχνευόταν μια παραβίαση;
15. Θέστε το ερώτημα renewal: πότε πρέπει να αρχίσει η ενέργεια;
16. Θέστε το ερώτημα revocation: ποιοι clients ελέγχουν CRL ή OCSP;
17. Θέστε το ερώτημα audit: ποια απόφαση μπορεί να ιχνηλατηθεί;
18. Εκτελέστε cleanup.
19. Τεκμηριώστε τις αποκλίσεις.
20. Μετατρέψτε το αποτέλεσμα σε σύντομη σύνοψη review.

10. Πίνακας review

Επίσημες αναφορές

• RFC 5280: Internet X.509 Public Key Infrastructure Certificate and CRL Profile: https://datatracker.ietf.org/doc/html/rfc5280
• CA/Browser Forum Baseline Requirements: https://cabforum.org/working-groups/server/baseline-requirements/requirements/
• NIST SP 800-57 Part 1 Revision 5: https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final
• OpenSSL Manual Pages: https://www.openssl.org/docs/manpages/

Παράρτημα παραδείγματος: Evidence, μεταφορά γνώσης και λειτουργία

Το παράρτημα ολοκληρώνει το παράδειγμα ως εκπαιδευτικό στοιχείο. Περιορίζεται σκόπιμα σε πραγματικά ερωτήματα PKI: περιεχόμενο certificate, trust chain, key material, revocation, renewal, audit και λειτουργική παράδοση.

Λίστα ελέγχου evidence

• Καταγράφηκε η έξοδος openssl version, ώστε να αντιστοιχίζεται η έξοδος σε συγκεκριμένη έκδοση εργαλείου.
• Ελέγχθηκαν subject, issuer, serial και διάρκεια ισχύος με openssl x509 -noout.
• Από το κείμενο του certificate εξήχθησαν SAN, basic constraints, key usage και EKU.
• Η chain επαληθεύτηκε με τη root CA ως trust anchor και την intermediate CA ως chain certificate.
• Οι αστοχίες δεν περιγράφηκαν απλώς· έγιναν ορατές με ελεγχόμενο exit code ή αρχείο evidence.
• Δεν αντιγράφηκαν private keys σε αρχεία evidence.
• Τα runtime artifacts βρίσκονται κάτω από το work/ και χωρίζονται από το περιεχόμενο του workshop.
• Το cleanup είναι δυνατό με αφαίρεση του work/.

Ερωτήσεις μεταφοράς γνώσης

1. Ποιος είναι υπεύθυνος για το certificate και ποιος μπορεί να εγκρίνει την έκδοσή του;
2. Ποια CA το υπογράφει και πώς προστατεύεται;
3. Ποιοι clients ή συστήματα πρέπει να εμπιστεύονται το trust anchor;
4. Ποια διάρκεια ισχύος δικαιολογείται και πότε αρχίζει το renewal;
5. Πώς διανέμεται το revocation και πώς ελέγχεται η συμπεριφορά των clients;
6. Ποια logs ή tickets αποδεικνύουν request, approval, issuance και change;
7. Ποια απόκλιση δεν θα ήταν αποδεκτή για δημόσια CA;
8. Ποια μέρη του lab πρέπει να αυτοματοποιηθούν μέσω HSM, Vault, cert-manager, ACME ή SPIFFE;

Λειτουργικές σημειώσεις

Σύνοψη review

Ένα παράδειγμα ολοκληρώνεται μόνο όταν συνδέονται σωστά η τεχνική εκτέλεση, η τεχνική εξήγηση και το evidence ασφάλειας. Για τα CA workshops αυτό έχει μεγαλύτερη σημασία από την ακολουθία εντολών μόνη της, επειδή ένα certificate μπορεί να παραμένει επικίνδυνο ακόμη κι αν το OpenSSL το δημιούργησε επιτυχώς.