שאלה הסמכה הסמכה שורש תעודת תפוגה וחידוש


בשנת 2004, הקמתי רשות הסמכה קטנה באמצעות OpenSSL על לינוקס ואת סקריפטים פשוטים לניהול מסופק עם OpenVPN. בהתאם למדריכים שמצאתי בזמנו, קבעתי את תקופת תוקפו של אישור ה- CA ל- 10 שנים. מאז, חתמתי על אישורים רבים עבור מנהרות OpenVPN, אתרי אינטרנט ושרתי דואר אלקטרוני, שלכולם יש גם תוקף של 10 שנים (זה אולי היה לא בסדר, אבל לא ידעתי אז טוב יותר).

מצאתי מדריכים רבים על הגדרת CA, אבל רק מעט מאוד מידע על הניהול שלה, ובמיוחד, על מה צריך להיעשות כאשר תעודת שורש CA יפוג, אשר יקרה קצת זמן בשנת 2014. אז יש לי את הפעולות הבאות שאלות:

  • האם התעודות בעלות תקופת תוקף שתארך לאחר פקיעת תעודת המקור של השורש תהיינה לא חוקיות עם תום תקופת תוקפן או שתמשיך להיות בתוקף (משום שהן נחתמו במהלך תקופת תוקפו של אישור CA)?
  • אילו פעולות נדרשות כדי לחדש את אישור ה- root של ה- CA ולהבטיח מעבר חלק במהלך פקיעתו?
    • אני יכול איכשהו לחתום מחדש את אישור השורש הנוכחי CA עם תקופת תוקפו שונה, ולהעלות את החדש חתום cert ללקוחות כך אישור הלקוח להישאר תקף?
    • לחלופין, האם עלי להחליף את כל אישורי הלקוח בחדשות חדשות חתומות על ידי אישור חדש של שורש CA?
  • מתי יש לחדש את אישור רשות השורש? קרוב לתוקף, או זמן סביר לפני פקיעת תוקפו?
  • אם חידוש תעודת ה- CA של השורש יהפוך לחלק גדול של עבודה, מה אוכל לעשות עכשיו טוב יותר כדי להבטיח מעבר חלק יותר בחידוש הבא (בקיצור של תקופת התוקף ל -100 שנים, כמובן)?

המצב נעשה קצת יותר מסובך על ידי העובדה כי הגישה היחידה שלי חלק מהלקוחות היא דרך מנהרה OpenVPN המשתמשת אישור חתום על ידי אישור CA הנוכחי, אז אם אני צריך להחליף את כל הלקוח certs, אני צריך להעתיק את הקבצים החדשים ללקוח, להפעיל מחדש את המנהרה, לחצות את האצבעות ומקווה שזה עולה אחר כך.


87
2017-08-30 08:34






תשובות:


שמירה על אותו מפתח פרטי ב- CA השורש מאפשרת לכל האישורים להמשיך ולאמת בהצלחה מול השורש החדש; כל מה שנדרש ממך הוא לסמוך על השורש החדש.

מערכת החתימה על האישור מבוססת על חתימה מהמפתח הפרטי; שמירה על אותו מפתח פרטי (וכן, במשתמע, אותו מפתח ציבורי) תוך יצירת תעודה ציבורית חדשה, עם תקופת תוקף חדשה וכל תכונות חדשות אחרות השתנו לפי הצורך, שומר על יחסי אמון במקום. CRLs, גם, יכול להמשיך מן הסמכה הישן החדש, כפי שהם, כמו אישורים, חתום על ידי המפתח הפרטי.


אז, בואו לאמת!

הפוך CA השורש:

openssl req -new -x509 -keyout root.key -out origroot.pem -days 3650 -nodes

צור ממנו אישור ילדים:

openssl genrsa -out cert.key 1024
openssl req -new -key cert.key -out cert.csr

חתום על אישור הילד:

openssl x509 -req -in cert.csr -CA origroot.pem -CAkey root.key -create_serial -out cert.pem
rm cert.csr

כל להגדיר שם, רגיל תעודת הקשר. בוא נבדוק את האמון:

# openssl verify -CAfile origroot.pem -verbose cert.pem
cert.pem: OK

אוקיי, אז, עכשיו נניח 10 שנים חלפו. בוא ניצור אישור ציבורי חדש מאותו מפתח פרטי של השורש.

openssl req -new -key root.key -out newcsr.csr
openssl x509 -req -days 3650 -in newcsr.csr -signkey root.key -out newroot.pem
rm newcsr.csr

ו .. האם זה עובד?

# openssl verify -CAfile newroot.pem -verbose cert.pem
cert.pem: OK

אבל למה? הם קבצים שונים, נכון?

# sha1sum newroot.pem
62577e00309e5eacf210d0538cd79c3cdc834020  newroot.pem
# sha1sum origroot.pem
c1d65a6cdfa6fc0e0a800be5edd3ab3b603e1899  origroot.pem

כן, אבל, זה לא אומר שהמפתח הציבורי החדש אינו תואם בקריפטוגרף את החתימה על האישור. מספרים סידוריים שונים, אותו מודולוס:

# openssl x509 -noout -text -in origroot.pem
        Serial Number:
            c0:67:16:c0:8a:6b:59:1d
...
            RSA Public Key: (1024 bit)
                Modulus (1024 bit):
                    00:bd:56:b5:26:06:c1:f6:4c:f4:7c:14:2c:0d:dd:
                    3c:eb:8f:0a:c0:9d:d8:b4:8c:b5:d9:c7:87:4e:25:
                    8f:7c:92:4d:8f:b3:cc:e9:56:8d:db:f7:fd:d3:57:
                    1f:17:13:25:e7:3f:79:68:9f:b5:20:c9:ef:2f:3d:
                    4b:8d:23:fe:52:98:15:53:3a:91:e1:14:05:a7:7a:
                    9b:20:a9:b2:98:6e:67:36:04:dd:a6:cb:6c:3e:23:
                    6b:73:5b:f1:dd:9e:70:2b:f7:6e:bd:dc:d1:39:98:
                    1f:84:2a:ca:6c:ad:99:8a:fa:05:41:68:f8:e4:10:
                    d7:a3:66:0a:45:bd:0e:cd:9d
# openssl x509 -noout -text -in newroot.pem
        Serial Number:
            9a:a4:7b:e9:2b:0e:2c:32
...
            RSA Public Key: (1024 bit)
                Modulus (1024 bit):
                    00:bd:56:b5:26:06:c1:f6:4c:f4:7c:14:2c:0d:dd:
                    3c:eb:8f:0a:c0:9d:d8:b4:8c:b5:d9:c7:87:4e:25:
                    8f:7c:92:4d:8f:b3:cc:e9:56:8d:db:f7:fd:d3:57:
                    1f:17:13:25:e7:3f:79:68:9f:b5:20:c9:ef:2f:3d:
                    4b:8d:23:fe:52:98:15:53:3a:91:e1:14:05:a7:7a:
                    9b:20:a9:b2:98:6e:67:36:04:dd:a6:cb:6c:3e:23:
                    6b:73:5b:f1:dd:9e:70:2b:f7:6e:bd:dc:d1:39:98:
                    1f:84:2a:ca:6c:ad:99:8a:fa:05:41:68:f8:e4:10:
                    d7:a3:66:0a:45:bd:0e:cd:9d

בוא נלך קצת יותר כדי לוודא שזה עובד אימות אמת בעולם האמיתי.

אש אפאצ 'י למשל, בואו לתת לו ללכת (מבנה הקובץ debian, להתאים לפי הצורך):

# cp cert.pem /etc/ssl/certs/
# cp origroot.pem /etc/ssl/certs/
# cp newroot.pem /etc/ssl/certs/
# cp cert.key /etc/ssl/private/

אנו נקבע את ההנחיות הבאות VirtualHost מקשיב על 443 - זוכר, newroot.pem אישור שורש אפילו לא קיים כאשר cert.pem נוצר וחתם.

SSLEngine on
SSLCertificateFile /etc/ssl/certs/cert.pem
SSLCertificateKeyFile /etc/ssl/private/cert.key
SSLCertificateChainFile /etc/ssl/certs/newroot.pem

בוא נבדוק את אופן הפתיחה של OpenSsl:

# openssl s_client -showcerts -CAfile newroot.pem -connect localhost:443

Certificate chain
 0 s:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=server.lan
   i:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
 1 s:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
   i:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
-----BEGIN CERTIFICATE-----
MIICHzCCAYgCCQCapHvpKw4sMjANBgkqhkiG9w0BAQUFADBUMQswCQYDVQQGEwJB
...
-----END CERTIFICATE-----
(this should match the actual contents of newroot.pem)
...
Verify return code: 0 (ok)

בסדר, ומה דעתך על דפדפן באמצעות ה- API של crypto MS? אני חייב לסמוך על השורש, קודם, אז הכל טוב, עם המספר הסידורי של השורש החדש:

newroot

וגם, אנחנו עדיין צריכים לעבוד עם השורש הישן, גם. החלף את תצורת Apache סביב:

SSLEngine on
SSLCertificateFile /etc/ssl/certs/cert.pem
SSLCertificateKeyFile /etc/ssl/private/cert.key
SSLCertificateChainFile /etc/ssl/certs/origroot.pem

האם להפעיל מחדש את מלא על אפאצ 'י, לטעון מחדש לא להחליף את הרשומות כראוי.

# openssl s_client -showcerts -CAfile origroot.pem -connect localhost:443

Certificate chain
 0 s:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=server.lan
   i:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
 1 s:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
   i:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
-----BEGIN CERTIFICATE-----
MIIC3jCCAkegAwIBAgIJAMBnFsCKa1kdMA0GCSqGSIb3DQEBBQUAMFQxCzAJBgNV
...
-----END CERTIFICATE-----
(this should match the actual contents of origroot.pem)
...
Verify return code: 0 (ok)

בנוסף, עם דפדפן ה- API של קריפטו MS, Apache מציג את השורש הישן, אבל השורש החדש עדיין בחנות השורש המהימן של המחשב. זה יהיה באופן אוטומטי למצוא אותו ולאמת את cert נגד שורש מהימן (חדש), למרות Apache הצגת שרשרת אחרת (השורש הישן). לאחר הפשטת שורש חדש מן השורשים מהימנים והוספת cert root המקורי, הכל טוב:

oldroot


אז זהו זה! שמור את אותו מפתח פרטי בעת חידוש, להחליף את השורש מהימן חדש, וזה פחות או יותר הכל פשוט עובד. בהצלחה!


124
2017-09-04 18:40



בכל מקרה, מה הטעם ליצור אישור שורש חדש אם אתה רק הולך לעשות שימוש חוזר באותו מפתח פרטי? אם תמשיך לעשות את זה שוב ושוב, אז מה הטעם אפילו שיש תאריך תפוגה עבור התעודה? חשבתי שתפילת השורש שימשה כדי לאלץ את מנהלי המערכת ליצור מפתח חדש יותר (סביר יותר) חזק יותר, שהוא מאובטח יותר כנגד המכונות המתקדמות אי פעם בניסיון לשבור את המפתחות. מפתח 40 סיביות שנעשו לפני 20 שנה אינו בטוח מספיק עבור - jvhashe
@jvhashe אם תעודת השורש כבר לא חזק מספיק cryptographically, אז אתה צריך להיות להיפטר ממנו ללא תלות תאריך תפוגה. אם אתה יוצר שורש משלך, אין שום דבר המונע ממך להגדיר אותו לפוג מאות שנים בעבר, כאשר אתה כבר לא תהיה על הפלנטה. התפוגה בקושי רלוונטית על תעודת שורש - ועל תעודת הילד, התפוגה היא לא ממש על כוח הצפנה או (לשאול את CAs אשר prepping לבטל את כל 1024 סיביות בחודש אוקטובר) - לראות כאן למידע נוסף. - Shane Madden♦
בנוסף לאמור לעיל, מצאתי כי המספר הסידורי צריך להיות זהה עבור שיטה זו לעבוד. - Scott Presnell
-set_serial 01 - WTF ??? אתה לא יכול מחדש מספרי הסדרה. האם אפילו התייעצת RFC 4158, אינטרנט X.509 מפתח ציבורי תשתית: בניין נתיב הסמכה? או שאתה פשוט עושה את זה כמו שאתה הולך יחד? אין לך מושג על הבעיות שאתה גורם בסוכני המשתמש כאשר הם מתחילים לבנות נתיב. - jww
@jww האם קראת את התשובה? זו רק הוכחה לכך שהקריפטוגרפיה עובדת. פקודה זו היא פשוט ליצור מבחן מבחן שאנחנו יכולים לאמת מאוחר יותר, לצורך בחינת הקשר בין ה- root הישן הישן החדש. אם מישהו J באמצעות פקודות אלה ישירות, אני בהחלט מקווה משהו נשבר, והם מבינים שהם צריכים לשים לב להקשר של משהו לפני עיוור מפעיל אותו (או עף את הידית על אם 01 הוא סידורי מקובל במעבדה). - Shane Madden♦


שמתי לב שתוספי CA עשויים להיות חסרים בתעודה המחודשת של מפתח CA המקורי. זה עבד יותר מתאים לי (זה יוצר ./renewedselfsignedca.conf שבו מוגדרים הרחבות CA v3, ו ca.key ו ca.crt הם המפתח המקורי CA אישור):

openssl x509 -x509toreq -in ca.crt -signkey ca.key -out renewedselfsignedca.csr
echo -e "[ v3_ca ]\nbasicConstraints= CA:TRUE\nsubjectKeyIdentifier= hash\nauthorityKeyIdentifier= keyid:always,issuer:always\n" > renewedselfsignedca.conf
openssl x509 -req -days 1095 -in renewedselfsignedca.csr -signkey ca.key -out renewedselfsignedca.crt -extfile ./renewedselfsignedca.conf -extensions v3_ca

13
2018-04-22 10:31



זה היה תוספת שימושית מאוד. התשובה תקפה למעשה לא לגרום לתעודה תואמת מספיק בשבילי אם יש לך הגדרות שרירותי על השורש המקורי שלך CA. - Theuni
שנית, מאוד מועיל. תוספת נוספת: כמו סקוט פרסנל בהערות לתשובה המקובלת, הייתי גם צריך לציין באופן ידני את המספר הסידורי הקסדצימלי של התעודה המחודשת, כך שתתאים לישן. משמעות הדבר היתה הוספה -set_serial 0xdeadbeefabba (לא הסידורי האמיתי לא :)) הפקודה האחרונה x509. רק אז אישורי הלקוח שלי הצליחו לאמת בהצלחה את אישור CA המחודש. - JK Laiho
שיטה זו קלה יותר משום שהיא שומרת על אותו מידע מאשר על האישור הקודם. - lepe
יצרתי סקריפט עבור פתרון זה בתוספת -set_serial - לראות את התשובה שלי - Wolfgang Fahl
תשובה זו הצילה אותי הרבה עבודה, לאחר ההוצאות כמעט יום על נושא זה נדרש, אני כמעט עומד לוותר, אני קצה הכובע שלי אליך על זה! - Onitlikesonic


מצב בסיסי כדי להאריך את תקופת שורש תקפה (אתה צריך את X.509 הציבור מפתח פרטית asociated):

צור את אחריות חברתית מהציבור X.509 ומפתח פרטי:

openssl x509 -x509toreq -in XXX.crt -signkey XXX.key -out XXX.csr

חתום מחדש על אחריות חברתית עם מפתח פרטי:

openssl x509 -in XXX.csr -out XXX.crt -signkey XXX.key -req -days 365

2
2018-01-22 16:35





כאשר פג תוקפה של תעודת הבסיס, כך גם הרשומות שחתמת עליהן. יהיה עליך ליצור שורש חדש cert ולחתום על אישורים חדשים עם זה. אם אינכם רוצים לחזור על התהליך כל כמה שנים, הרי שהאפשרות האמיתית היחידה היא להאריך את התאריך התקף בשורש הבסיס משהו כמו עשר או עשרים שנה: השורש שיצרתי לשימוש עצמי קבעתי עשרים שנה.

אתה לא יכול "לחדש" שורש cert. כל מה שאתה יכול לעשות הוא ליצור אחד חדש.

צור שורש חדש לפחות שנה או שתיים לפני הישן שלך יפוג אז יש לך זמן לשנות את מבלי להיות נגד קיר זמן אם משהו משתבש. בדרך זו אתה תמיד יכול לעבור באופן זמני בחזרה את certs הישן עד שאתה מקבל את בעיות בקיעת שיניים עם אחד חדש נפתרה.

באשר למנהרות VPN ללכת, הייתי להגדיר כמה שרתים testbed להתנסות כך אתה מבין בדיוק מה שאתה צריך לעשות לפני שאתה עושה את זה עם המחשב של הלקוח.


0
2017-09-03 23:59



תשובה זו נראה כי ניתן לחדש תעודת שורש, על ידי שימוש חוזר המפתח שלה. אבל אני חושד שזה לא שונה מלכתחילה, כמו cert החדש יהיה חתימה שונה, ולכן לא לאמת את הלקוח הקיים certs. - Remy Blank
כן, אתה יכול להאריך תקופה תקפה ... והוא פחות עבודה מאשר ליצור מחדש את כל pki, אישורי הלקוח, מחדש שורש חדש ... - ggrandes
החלק על הנפקת אישורי קופה חדשים אינו בהכרח נכון. זה תלוי איך המזהה מפתח הרשות (AKID) מיוצג הכפופים CA ו אישורים סופיים. אם AKID מבוסס על {שם מובחן, מספר סידורי}, אז המשכיות תושג. ראה גם RFC 4518, אינטרנט X.509 תשתית מפתח ציבורי: בניין נתיב הסמכה. - jww


@Bianconiglio פלוס --set_serial עבד בשבילי. השרת שלי הוא אינטראנט רק אז אני לא לדאוג הרבה מה תופעות הלוואי הם עכשיו יש לי זמן לעבוד על פתרון "תקין".

השתמשתי סקריפט להגדרה הבאה. רק להגדיר את המשתנים CACRT, KAKEY ו NEWCA.

# WF 2017-06-30
# https://serverfault.com/a/501513/162693
CACRT=SnakeOilCA.crt
CAKEY=SnakeOilCA.key
NEWCA=SnakeOilCA2017
serial=`openssl x509 -in $CACRT -serial -noout | cut -f2 -d=`
echo $serial
openssl x509 -x509toreq -in $CACRT -signkey $CAKEY -out $NEWCA.csr
echo -e "[ v3_ca ]\nbasicConstraints= CA:TRUE\nsubjectKeyIdentifier= hash\nauthorityKeyIdentifier= keyid:always,issuer:always\n" > $NEWCA.conf
openssl x509 -req -days 3650 -in $NEWCA.csr -set_serial 0x$serial -signkey $CAKEY -out $NEWCA.crt -extfile ./$NEWCA.conf -extensions v3_ca
openssl x509 -in $NEWCA.crt -enddate -serial -noout

0
2018-06-30 17:33





היתה לנו אותה בעיה, וזה היה במקרה שלנו, כי שרת דביאן היה עד כה, ואת openSSL היה בעיה זו:

https://en.wikipedia.org/wiki/Year_2038_problem

הגירסה האחרונה של OpenSSL הזמינה עבור Debian 6 מביאה את הבעיה. כל האישורים שנוצרו לאחר 23.01.2018 מייצרת Vality: עבור 1901 שנה!

הפתרון הוא לעדכן את OpenSSL. ניתן ליצור שוב את קבצי התצורה (עם האישורים) עבור הלקוחות.


0
2018-03-09 10:38