ಕ್ರಾಸ್-ಸೈನ್ ಮಾಡಿದ CA: ಕೀಲಿ ಹೊಂದುತ್ತದೆ, AKI ಬಂಧ ಹೊಂದುವುದಿಲ್ಲ

ಎರಡು CA ಪ್ರಮಾಣಪತ್ರಗಳು ಒಂದೇ ಸಾರ್ವಜನಿಕ ಕೀಲಿ ಮತ್ತು ಒಂದೇ subject ಹೊಂದಿದ್ದರೂ ಪರಸ್ಪರ ಬದಲಾಯಿಸಲಾಗದಿರಬಹುದು. ಒಂದು ಸ್ವಯಂ-ಸಹಿ ಮಾಡಿದ್ದು, ಇನ್ನೊಂದು ಹಳೆಯ ಮೂಲದಿಂದ ಕ್ರಾಸ್-ಸಹಿ ಮಾಡಿದ್ದು, ಮತ್ತು ಅವುಗಳ ನೀಡುಗ ಹೆಸರುಗಳು, ಕ್ರಮ ಸಂಖ್ಯೆಗಳು ಮತ್ತು ಸಹಿಗಳು ಭಿನ್ನವಾಗಿವೆ. ಎಲೆ ತನ್ನ Authority Key Identifier ಮೂಲಕ ನಿರ್ದಿಷ್ಟವಾಗಿ ಅವುಗಳಲ್ಲಿ ಒಂದಕ್ಕೆ ಬಂಧಿಸಿಕೊಳ್ಳಬಹುದು. ಆ ಬಂಧ ಕ್ಲೈಂಟ್ ತಪ್ಪು ಸರಪಣಿಯನ್ನು ಆರಿಸಿ handshake ಸ್ಪಷ್ಟ ಕಾರಣವಿಲ್ಲದೆ ವಿಫಲವಾಗುವವರೆಗೆ ಅಗೋಚರವಾಗಿ ಉಳಿಯುತ್ತದೆ.

ಈ ಐದು ಪರಿಶೀಲನೆಗಳನ್ನು ಕ್ರಮವಾಗಿ ಮಾಡಿ: ಪ್ರತಿಯೊಂದೂ ಬೇರೆ ವೈಫಲ್ಯವನ್ನು ಹೊರಗಿಡುತ್ತದೆ.

ಪರಿಶೀಲನೆ 1: ಟೆಂಪ್ಲೇಟ್ ಮುಟ್ಟುವ ಮೊದಲು ಎರಡೂ ಸರಪಣಿಗಳನ್ನು ಬಿಡಿಸಿ

ಮಾರ್ಗಗಳನ್ನು ಬರೆಯಿರಿ. ಹಳೆಯ ಜನಸಂಖ್ಯೆ ಹಳೆಯ ಮೂಲ A ಅನ್ನು ನಂಬುತ್ತದೆ, ಅದು CA B ಅನ್ನು ನೀಡಿತು, ಅದು ಸರ್ವರ್ ಎಲೆಯನ್ನು ನೀಡಿತು. ಹೊಸ ಜನಸಂಖ್ಯೆ ಸ್ವಯಂ-ಸಹಿ ಮಾಡಿದ CA B ಅನ್ನು ನೇರವಾಗಿ ನಂಬುತ್ತದೆ. ಎರಡೂ B ಪ್ರಮಾಣಪತ್ರಗಳು ಒಂದೇ ಕೀಲಿ ಮತ್ತು subject ಹೊಂದಿವೆ, ಮತ್ತು ಅದಕ್ಕೇ subject ಸಾಲನ್ನು ಓದುವ ವ್ಯಕ್ತಿ ಒಂದು CA ಕಾಣುವಲ್ಲಿ ಕ್ಲೈಂಟ್ ಎರಡನ್ನು ಕಾಣುತ್ತದೆ.

ಕ್ರಾಸ್-ಸಹಿ ಮಾಡಿದ ಪ್ರತಿಯೂ ನಿಜವಾದ CA ಪ್ರಮಾಣಪತ್ರವಾಗಿರಬೇಕು, basic constraints ಮತ್ತು key usage ಸಹಿ ಮಾಡಲು ಅನುಮತಿಸಬೇಕು.

ಪರಿಶೀಲನೆ 2: ಕೀಲಿಯಷ್ಟೇ ಅಲ್ಲ, AKI ಕ್ಷೇತ್ರಗಳನ್ನು ಹೋಲಿಸಿ

ಎಲೆಯ ನೀಡುಗ ಹೆಸರು B ಯ subject ಗೆ ಹೊಂದಬೇಕು, ಮತ್ತು ಆ ಭಾಗ ಸಾಮಾನ್ಯವಾಗಿ ನಿಲ್ಲುತ್ತದೆ. ಎರಡು ಪ್ರತಿಗಳು ಬೇರ್ಪಡುವ ಸ್ಥಳ Authority Key Identifier, ಏಕೆಂದರೆ ಅದು ಕೀಲಿ ಗುರುತಿಸುವಿಕೆ, ನೀಡುಗ ಪ್ರಮಾಣಪತ್ರ ಮತ್ತು ಕ್ರಮ ಸಂಖ್ಯೆಯನ್ನು ಹೊತ್ತೊಯ್ಯಬಹುದು. ಕೀಲಿ ಗುರುತಿಸುವಿಕೆ ಎರಡೂ ಪ್ರತಿಗಳಿಗೆ ಹೊಂದುತ್ತದೆ, ಏಕೆಂದರೆ ಕೀಲಿ ಒಂದೇ. ನೀಡುಗ ಮತ್ತು ಕ್ರಮ ಸಂಖ್ಯೆ ಕ್ಷೇತ್ರಗಳು ನಿಖರವಾಗಿ ಒಂದಕ್ಕೆ ಹೊಂದುತ್ತವೆ, ಆದ್ದರಿಂದ ಸ್ವಯಂ-ಸಹಿ ಪ್ರತಿಯ ವಿರುದ್ಧ ನಿರ್ಮಿಸಿದ ಸರಪಣಿ ಕ್ರಾಸ್-ಸಹಿ ಪ್ರತಿಯ ವಿರುದ್ಧ ವಿಫಲವಾಗಬಹುದು.

ಊಹಿಸುವ ಬದಲು ಎಲೆಯನ್ನು ಪರೀಕ್ಷಿಸಿ: openssl x509 -in server.pem -noout -ext authorityKeyIdentifier.

ನಂತರ ಎರಡೂ ಅಭ್ಯರ್ಥಿಗಳನ್ನು openssl x509 -in b-cross.pem -noout -text | grep -A2 "Authority Key Identifier" ನೊಂದಿಗೆ ಹೋಲಿಸಿ, ಮತ್ತು ಅದೇ ಆಜ್ಞೆಯನ್ನು ಸ್ವಯಂ-ಸಹಿ ಪ್ರತಿಯ ವಿರುದ್ಧ ಚಲಾಯಿಸಿ.

ಎಲೆ ನೀಡುಗ ಮತ್ತು ಕ್ರಮ ಸಂಖ್ಯೆಯನ್ನು ಹೊತ್ತಿದ್ದರೆ, ಆ ಮೌಲ್ಯಗಳು ವಿವರಿಸುವ ಪ್ರಮಾಣಪತ್ರವೊಂದೇ ಸರಪಣಿಯನ್ನು ಪೂರ್ಣಗೊಳಿಸುತ್ತದೆ, ಕ್ಲೈಂಟ್ ಯಾವ ಪ್ರತಿಯನ್ನು ಲೋಡ್ ಮಾಡಿದ್ದರೂ.

ಪರಿಶೀಲನೆ 3: ನೀಡುವಿಕೆ ನೀತಿಯನ್ನು ಬದಲಿಸಿ, ಸಹಿ ಮಾಡಿದ ಬೈಟ್‌ಗಳನ್ನಲ್ಲ

ವಿಸ್ತರಣೆಗಳು ಸಹಿಯ ಒಳಗೆ ಇರುತ್ತವೆ. ಇರುವ ಎಲೆಯ ಮೇಲೆ ಒಂದನ್ನು ಸೇರಿಸುವುದು, ತೆಗೆಯುವುದು ಅಥವಾ ಸಂಪಾದಿಸುವುದು ದುರಸ್ತಿಯಲ್ಲ, ಅದು ಬೇರೆ ಪ್ರಮಾಣಪತ್ರ, ಮತ್ತು ಮತ್ತೆ ನೀಡಬೇಕಾಗುತ್ತದೆ. ಬದಲಾವಣೆ ನೀಡುವಿಕೆ ನೀತಿಗೆ ಸೇರುತ್ತದೆ: authorityKeyIdentifier = keyid,issuer:always ಹೊಸ ಎಲೆಗಳಿಗೆ ಪ್ರಮಾಣಪತ್ರ-ನಿರ್ದಿಷ್ಟ ಬಂಧವನ್ನು ಹೊತ್ತೊಯ್ಯಲು ಮಾಡುತ್ತದೆ, ಆದರೆ keyid ಒಂಟಿಯಾಗಿ ಉದ್ದೇಶಪೂರ್ವಕ ಕ್ರಾಸ್-ಸೈನಿಂಗ್ ಪರಿವರ್ತನೆಗೆ ಸರಿಹೊಂದುವ ಸಡಿಲ ರೂಪವನ್ನು ಉಳಿಸುತ್ತದೆ. ಮುಂದಿನ ಬ್ಯಾಚ್ ಸಹಿ ಆಗುವ ಮೊದಲು ನಿಮ್ಮ PKI ಯಾವುದನ್ನು ಬಯಸುತ್ತದೆ ಎಂದು ನಿರ್ಧರಿಸಿ.

ಹಂಚಿಕೊಂಡ ಟೆಂಪ್ಲೇಟ್ ಸಂಪಾದಿಸುವುದು ನಿಮ್ಮ ಮುಂದಿರುವ ಸರ್ವರ್ ಮಾತ್ರವಲ್ಲ, ಪ್ರತಿ ಭವಿಷ್ಯದ ಪ್ರಮಾಣಪತ್ರವನ್ನೂ ಬದಲಿಸುತ್ತದೆ.

ಪರಿಶೀಲನೆ 4: ಪ್ರತಿ ವಿಶ್ವಾಸ ಜನಸಂಖ್ಯೆಯನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಪರಿಶೀಲಿಸಿ

ಹಳೆಯ ಮಾರ್ಗ ಮತ್ತು ಹೊಸ ಮಾರ್ಗವನ್ನು ಪ್ರತ್ಯೇಕ ರನ್‌ಗಳಾಗಿ ಪರೀಕ್ಷಿಸಿ. openssl verify -purpose sslserver -verify_hostname vpn.example -CAfile old-root.pem -untrusted b-cross-signed.pem server.pem ಕ್ರಾಸ್-ಸಹಿ ಮಾರ್ಗವನ್ನು ಅಭ್ಯಾಸ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಹೊಸ ಮೂಲ ಮತ್ತು untrusted ಕಡತವಿಲ್ಲದ ಅದೇ ಆಜ್ಞೆ ಸ್ವಯಂ-ಸಹಿ ಮಾರ್ಗವನ್ನು ಅಭ್ಯಾಸ ಮಾಡುತ್ತದೆ. ಎರಡೂ ಮೂಲಗಳನ್ನು ಒಂದೇ ಬಂಡಲ್‌ನಲ್ಲಿ ಮಿಶ್ರ ಮಾಡುವುದು ಯಾವ ಸರಪಣಿ ಆಯ್ಕೆಯಾಯಿತು ಎಂಬುದನ್ನು ಮರೆಮಾಡುತ್ತದೆ. ನಂತರ ನಿಜವಾದ ಕ್ಲೈಂಟ್‌ಗಳೊಂದಿಗೆ ಪುನರಾವರ್ತಿಸಿ, ಏಕೆಂದರೆ VPN ಬ್ಯಾಕೆಂಡ್ ಸರಪಣಿಗೆ ಆದ್ಯತೆ ನೀಡಬಹುದು ಅಥವಾ ಪ್ರಮಾಣಪತ್ರವನ್ನು ಪಿನ್ ಮಾಡಬಹುದು openssl ಮಾಡದ ರೀತಿಗಳಲ್ಲಿ.

ಮಧ್ಯವರ್ತಿ ಪ್ರಮಾಣಪತ್ರವನ್ನು ಕ್ಲೈಂಟ್ ನಿಜವಾಗಿ ಓದುವ ಸೇವಾ ಸಂರಚನೆಯ ಮೂಲಕ ಕಳುಹಿಸಿ, ವಿಕಿ ಪುಟದ ಮೂಲಕವಲ್ಲ.

ಪರಿಶೀಲನೆ 5: ಹಳೆಯ ಮಾರ್ಗವನ್ನು ನಿವೃತ್ತಿ ಗಡಿಯಾರದಲ್ಲಿ ಇರಿಸಿ

ಕ್ರಾಸ್-ಸೈನಿಂಗ್ ವಿನ್ಯಾಸದಿಂದಲೇ ಹಳೆಯ ವಿಶ್ವಾಸ ಮಾರ್ಗವನ್ನು ಜೀವಂತವಾಗಿ ಇಡುತ್ತದೆ, ಅದೇ ಉದ್ದೇಶ ಮತ್ತು ಅಪಾಯ. ಅದು ರಾಜಿಯಾದ ಹಳೆಯ ಮೂಲವನ್ನು ಸರಿಪಡಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಆ ಮೂಲವನ್ನು ಯಾವುದೇ ಕ್ಲೈಂಟ್‌ನಿಂದ ತೆಗೆಯುವುದಿಲ್ಲ. ಹಳೆಯ ಮಾರ್ಗ ಯಾವಾಗ ವಿಶ್ವಾಸ ನೀಡುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ ಎಂದು ಬರೆಯಿರಿ, ಮತ್ತು ಆ ದಿನ ನಿಜವಾಗಿ ಬರುತ್ತದೆ ಎಂದು ದೃಢೀಕರಿಸಿ.

ಎಲೆಗಳು ಸರಿಯುವ ಮೊದಲು ಪ್ರತಿ ಕ್ಲೈಂಟ್ ಹೊಸ ಮೂಲವನ್ನು ಸ್ವೀಕರಿಸಬಹುದಾದರೆ, ಸರಳ ದ್ವಿ-ವಿಶ್ವಾಸ ರೋಲ್‌ಔಟ್ ಕ್ರಾಸ್-ಸೈನಿಂಗ್‌ಗಿಂತ ಸುಲಭ, ಮತ್ತು ನಿವೃತ್ತಿ ಮಾಡಲು ಒಂದು ವಸ್ತು ಕಡಿಮೆ ಬಿಡುತ್ತದೆ.