ಬೆಂಬಲಿಸದ ಪ್ರಮಾಣಪತ್ರ ಉದ್ದೇಶ: ಮಧ್ಯವರ್ತಿ CA ಏಕೆ ವಿಫಲವಾಗುತ್ತದೆ
OpenVPN ಬೆಂಬಲಿಸದ ಪ್ರಮಾಣಪತ್ರ ಉದ್ದೇಶವನ್ನು ವರದಿ ಮಾಡಿದಾಗ, ಎಲೆ ಪ್ರಮಾಣಪತ್ರ ದೋಷರಹಿತವಾಗಿರಬಹುದು. ಏನನ್ನೂ ಮರುನೀಡುವ ಮೊದಲು ಎಲೆಯ ಉದ್ದೇಶವನ್ನು ಸರಪಳಿಯ ನೀತಿಯೊಂದಿಗೆ ಹೋಲಿಸಿ.
ಸರ್ವರ್ ಪ್ರಮಾಣಪತ್ರದ ಉದ್ದೇಶ ಸರಿಯಾಗಿ ಕಾಣುತ್ತದೆ, ಕೀ ಹೊಂದಿಕೆಯಾಗುತ್ತದೆ, ದಿನಾಂಕಗಳು ಸರಿವೆ, ಆದರೂ ಸಂಪರ್ಕ unsupported certificate purpose ದೊಂದಿಗೆ ವಿಫಲವಾಗುತ್ತದೆ. ಇದನ್ನು ಪರಿಹರಿಸುವ ವಿವರ ಸಾಮಾನ್ಯವಾಗಿ ದೋಷದ ಅದೇ ಸಾಲಿನಲ್ಲಿರುತ್ತದೆ: ಸರಪಳಿಯಲ್ಲಿ ಮೇಲಿನ ಪ್ರಮಾಣಪತ್ರವನ್ನು ಹೆಸರಿಸುವ ಆಳದ ಮೌಲ್ಯ ಮತ್ತು subject. ಎರಡು ವಿಭಿನ್ನ ಪರೀಕ್ಷೆಗಳು ನಡೆಯುತ್ತಿವೆ, ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಒಂದು ಮಾತ್ರ ಎಲೆಗೆ ಸಂಬಂಧಿಸಿದೆ. ಅವುಗಳನ್ನು ಹೋಲಿಸುವುದು ಸರ್ವರ್ ಪ್ರಮಾಣಪತ್ರವನ್ನು ಬದಲಿಸುವುದರಿಂದ ಏಕೆ ಏನೂ ಬದಲಾಗುವುದಿಲ್ಲ ಎಂಬುದನ್ನು ವಿವರಿಸುತ್ತದೆ.
ಪರಿಶೀಲಕನು ನಿಜವಾಗಿ ತಿರಸ್ಕರಿಸಿದ ಪ್ರಮಾಣಪತ್ರ ಯಾವುದು
ಸರಪಳಿ ಮೂರು ಬಾರಿ ಪುನರಾವರ್ತಿಸಿದ ಒಂದು ವಸ್ತುವಲ್ಲ. ಎಲೆ ಸರ್ವರ್ನ ಹೆಸರು ಮತ್ತು ಕೀಯನ್ನು ಹೊತ್ತೊಯ್ಯುತ್ತದೆ, ಮಧ್ಯವರ್ತಿ ಪ್ರಮಾಣಪತ್ರಗಳು ಅದನ್ನು ಮೂಲಕ್ಕೆ ಜೋಡಿಸುತ್ತವೆ, ಮತ್ತು ಪ್ರತಿಯೊಂದಕ್ಕೂ ತನ್ನದೇ ಆದ ಮಾನ್ಯತಾ ಅವಧಿ, ನಿರ್ಬಂಧಗಳು ಮತ್ತು ಬಳಕೆಗಳಿವೆ. ದೋಷವು ಆಳವನ್ನು ಹೆಸರಿಸಿದಾಗ, ಆ ಸಂಖ್ಯೆ ಪರಿಶೀಲಕನು ನಿರ್ಮಿಸಿದ ಸರಪಳಿಯಲ್ಲಿನ ಸ್ಥಾನವನ್ನು ಗುರುತಿಸುತ್ತದೆ, ಮತ್ತು ಸರ್ವರ್ ಅನಿರೀಕ್ಷಿತ ಸರಪಳಿಯನ್ನು ಕಳುಹಿಸಿದರೆ ಅದು ನೀವು ನಿರೀಕ್ಷಿಸುವ ಸ್ಥಾನವಲ್ಲದಿರಬಹುದು.
ಆ ಆಳದಲ್ಲಿನ ಪ್ರಮಾಣಪತ್ರದ ಕ್ಷೇತ್ರಗಳನ್ನು ಓದಿ, ನೀವು ದೋಷಿ ಎಂದು ಭಾವಿಸಿದ ಪ್ರಮಾಣಪತ್ರದ್ದಲ್ಲ. ಪ್ರತಿ ಕ್ಷೇತ್ರವನ್ನೂ ಸುರಿಯುವ ಬದಲು ನೀಡುವಿಕೆಯನ್ನು ನಿರ್ಬಂಧಿಸುವ ಎರಡು ವಿಸ್ತರಣೆಗಳನ್ನು ಕೇಳಿ, ಏಕೆಂದರೆ ಉತ್ತರ ಬಹುತೇಕ ಯಾವಾಗಲೂ ಅವುಗಳಲ್ಲಿ ಒಂದರಲ್ಲಿರುತ್ತದೆ. ವಿಸ್ತರಣೆಗಳ ಔಟ್ಪುಟ್ ಹಂಚಿಕೊಳ್ಳಲು ಸುರಕ್ಷಿತ; ಖಾಸಗಿ ಕೀಗಳನ್ನು ಎಂದಿಗೂ ಅಲ್ಲ.
openssl x509 -in issuing-ca.pem -noout -subject -issuer -ext basicConstraints -ext extendedKeyUsage
ಹೆಸರಿಸಿದ ಪ್ರಮಾಣಪತ್ರವು ಮಧ್ಯವರ್ತಿ ಪ್ರಮಾಣಪತ್ರವಾಗಿದ್ದು ಅದರ ವಿಸ್ತೃತ ಕೀ ಬಳಕೆ TLS ಸರ್ವರ್ ದೃಢೀಕರಣಕ್ಕೆ ಸಂಬಂಧವಿಲ್ಲದ್ದನ್ನು ಉಲ್ಲೇಖಿಸಿದರೆ, ಉಳಿದ ವೈಫಲ್ಯ ಯಾಂತ್ರಿಕವಾಗಿ ಅನುಸರಿಸುತ್ತದೆ. OpenVPN ಕೇಳಿದ ಉದ್ದೇಶಕ್ಕೆ ಸರಪಳಿಯನ್ನು ಬಳಸಲಾಗುವುದಿಲ್ಲ.
ಎಲೆಯ ಉದ್ದೇಶ ಮತ್ತು ಸರಪಳಿಯ ನೀತಿ ಎರಡು ಪರೀಕ್ಷೆಗಳು
ಎಲೆ ಪರೀಕ್ಷೆ ಕಿರಿದಾದ ಪ್ರಶ್ನೆ ಕೇಳುತ್ತದೆ: ಈ ಅಂತಿಮ ಘಟಕ ಪ್ರಮಾಣಪತ್ರವು ಈ ಹೆಸರಿಗೆ ಸರ್ವರ್ ದೃಢೀಕರಣವನ್ನು ಅನುಮತಿಸುತ್ತದೆಯೇ? ಸರಪಳಿ ಪರೀಕ್ಷೆ ಹೆಚ್ಚು ವಿಶಾಲವಾದದ್ದನ್ನು ಕೇಳುತ್ತದೆ: ಮಾರ್ಗದ ಪ್ರತಿ ಪ್ರಮಾಣಪತ್ರವೂ ಆ ಉದ್ದೇಶಕ್ಕೆ ಸೇವೆ ಸಲ್ಲಿಸಬಹುದೇ? ಕ್ಲೈಂಟ್ ಪ್ರಮಾಣಪತ್ರಗಳನ್ನು ಮಾತ್ರ ನೀಡಲು ಅನುಮತಿಸಲಾದ ಪ್ರಮಾಣಪತ್ರ ಪ್ರಾಧಿಕಾರವು ತನ್ನದೇ ಸಹಿ ಪರಿಶೀಲನೆಗಳನ್ನು ಪಾಸ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ಆದರೂ ಎರಡನೇ ಪರೀಕ್ಷೆಯಲ್ಲಿ ವಿಫಲವಾಗುತ್ತದೆ, ಏಕೆಂದರೆ ಅದು ಅಧಿಕಾರ ನೀಡುವ ಮಾರ್ಗವು ಅಪ್ಲಿಕೇಶನ್ಗೆ ಬೇಕಾದ ಉದ್ದೇಶವನ್ನು ಒಳಗೊಂಡಿಲ್ಲ. ಎರಡೂ ಪರೀಕ್ಷೆಗಳು ಒಂದೇ ಪದಗಳೊಂದಿಗೆ ವಿಫಲವಾಗುತ್ತವೆ ಮತ್ತು ಸಂಪೂರ್ಣವಾಗಿ ವಿಭಿನ್ನ ಪರಿಹಾರಗಳನ್ನು ಹೊಂದಿವೆ.
ಅದಕ್ಕಾಗಿಯೇ ಹೊಸದಾಗಿ ನೀಡಲಾದ ಎಲೆ, ಪ್ರತಿ ಗೋಚರ ಕ್ಷೇತ್ರದಲ್ಲೂ ಸರಿಯಾಗಿದ್ದರೂ, ತಕ್ಷಣ ವಿಫಲವಾಗಬಹುದು. ಅದಕ್ಕಾಗಿಯೇ ಪರಿಹಾರ ಸಾಮಾನ್ಯವಾಗಿ VPN ಸಂರಚನೆಯಲ್ಲದೆ ನೀಡುವ ಪ್ರಾಧಿಕಾರದ ಪ್ರೊಫೈಲ್ನಲ್ಲಿರುತ್ತದೆ.
ಗೈರುಹಾಜರಾದ EKU ನಿರ್ಬಂಧಕ EKU ಅಲ್ಲ
RFC 5280 ವಿಸ್ತೃತ ಕೀ ಬಳಕೆ ವಿಸ್ತರಣೆಯನ್ನು ಐಚ್ಛಿಕಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ಅದು ಇದ್ದಾಗ ನಿರ್ಬಂಧಕವಾಗಿರುತ್ತದೆ. ಆದ್ದರಿಂದ ವಿಸ್ತರಣೆ ಇಲ್ಲದ CA ಪ್ರಮಾಣಪತ್ರವು ಸರ್ವರ್ ದೃಢೀಕರಣಕ್ಕೆ 'ಇಲ್ಲ' ಎಂದು ಹೇಳಿಲ್ಲ, ಆದರೆ ಸಂಬಂಧವಿಲ್ಲದ ಉದ್ದೇಶವನ್ನು ಮಾತ್ರ ಪಟ್ಟಿ ಮಾಡುವ ಪ್ರಮಾಣಪತ್ರವು ಬಹಳ ನಿರ್ದಿಷ್ಟವಾದದ್ದನ್ನು ಹೇಳಿದೆ. ಈ ಎರಡು ಸ್ಥಿತಿಗಳನ್ನು ಸಮಾನವೆಂದು ಪರಿಗಣಿಸುವುದು ತಪ್ಪು ರೋಗನಿರ್ಣಯ ಮತ್ತು ಅದಕ್ಕಿಂತ ಕೆಟ್ಟದಾಗಿ ತಪ್ಪು ಪರಿಹಾರವನ್ನು ನೀಡುತ್ತದೆ. ಈ ವ್ಯತ್ಯಾಸವು ಕನ್ಸೋಲ್ನಲ್ಲಿ ಒಂದೇ ರೀತಿ ಕಾಣುವ ಎರಡು ಪ್ರಾಧಿಕಾರಗಳು ಸರಪಳಿಯಲ್ಲಿ ಸಂಪೂರ್ಣವಾಗಿ ವಿಭಿನ್ನವಾಗಿ ವರ್ತಿಸುವುದನ್ನು ಸಹ ವಿವರಿಸುತ್ತದೆ.
ಗ್ರಂಥಾಲಯಗಳ ವರ್ತನೆಯೂ ಇಲ್ಲಿ ಏಕರೂಪವಲ್ಲ. OpenSSL ನ ಪರಿಶೀಲನಾ ಆಯ್ಕೆಗಳ ದಾಖಲೆ CA ಪ್ರಮಾಣಪತ್ರಗಳ ಮೇಲಿನ ಉದ್ದೇಶ ಪರಿಶೀಲನೆಗಳ ತನ್ನದೇ ವಿಧಾನವನ್ನು ವಿವರಿಸುತ್ತದೆ, ಮತ್ತು ಆ ವಿಧಾನವು ಅನುಷ್ಠಾನ ನೀತಿಯೇ ಹೊರತು ಪ್ರತಿ TLS ಸ್ಟ್ಯಾಕ್ ಒಂದೇ ರೀತಿ ಅನುಸರಿಸುವ ನಿಯಮವಲ್ಲ. ನಿಮ್ಮ ಪರಿಶೀಲಕ ಏನು ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ವಿವರಿಸಿ, ನಂತರ ನೀವು ನಿಜವಾಗಿ ಚಲಾಯಿಸುವ ಆವೃತ್ತಿಯ ವಿರುದ್ಧ ಅದನ್ನು ದೃಢೀಕರಿಸಿ.
ಮರುನೀಡುವ ಮೊದಲು ವೈಫಲ್ಯವನ್ನು ಆಫ್ಲೈನ್ನಲ್ಲಿ ಮರುಸೃಷ್ಟಿಸಿ
ಆಫ್ಲೈನ್ ಪರಿಶೀಲನೆ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಸಮೀಕರಣದಿಂದ ಹೊರಗಿಡುತ್ತದೆ. ಅದೇ ಉದ್ದೇಶದ ಅಡಿಯಲ್ಲಿ ಸರಪಳಿ ಅದೇ ರೀತಿ ವಿಫಲವಾದರೆ, ಪ್ರಮಾಣಪತ್ರವೇ ಸಮಸ್ಯೆ ಮತ್ತು ಯಾವುದೇ ಸರ್ವರ್ ಸಂರಚನೆ ಅದನ್ನು ಮರೆಮಾಡಲಾರದು. ಸರಪಳಿ ಆಫ್ಲೈನ್ನಲ್ಲಿ ಪಾಸ್ ಆದರೂ ಸೇವೆ ಇನ್ನೂ ನಿರಾಕರಿಸಿದರೆ, ಅಪ್ಲಿಕೇಶನ್ ಬೇರೆ ಉದ್ದೇಶವನ್ನು ಕೇಳುತ್ತಿದೆ ಅಥವಾ ನೀವು ಪರೀಕ್ಷಿಸಿದ್ದಕ್ಕಿಂತ ಬೇರೆ ಸರಪಳಿಯನ್ನು ಬಳಸುತ್ತಿದೆ.
openssl verify -purpose sslserver -show_chain -CAfile root-ca.pem -untrusted issuing-ca.pem vpn-server.pem
-show_chain ಮುಖ್ಯ ಏಕೆಂದರೆ ಅದು ಉಪಕರಣ ನಿರ್ಮಿಸಿದ ಮಾರ್ಗವನ್ನು ಮುದ್ರಿಸುತ್ತದೆ, ಮತ್ತು ಅದು ಸಾಮಾನ್ಯವಾಗಿ ನೀವು ನೀಡಿದ ಫೈಲ್ ಕ್ರಮವಲ್ಲ. ಆ ಔಟ್ಪುಟ್ ಎರಡನೇ ಮಧ್ಯವರ್ತಿ ಪ್ರಮಾಣಪತ್ರವನ್ನು ಟ್ರಸ್ಟ್ ಸ್ಟೋರ್ನಿಂದ ಎಳೆಯಲಾಗುತ್ತಿದೆ ಎಂದೂ, ಸರ್ವರ್ ನೀವು ಉದ್ದೇಶಿಸದ ಕ್ರಾಸ್-ಸೈನ್ಡ್ ರೂಪಾಂತರವನ್ನು ಕಳುಹಿಸುತ್ತಿದೆ ಎಂದೂ, ಅಥವಾ ಟ್ಯುಟೋರಿಯಲ್ನಿಂದ ನಕಲಿಸಿದ ಉದ್ದೇಶ ಧ್ವಜವು ಸೇವೆ ಸಲ್ಲಿಸುತ್ತಿರುವ ಪಾತ್ರಕ್ಕಿಂತ ಬೇರೆ ಪಾತ್ರಕ್ಕೆ ಸೇರಿದೆ ಎಂದೂ ಕಂಡುಹಿಡಿಯುವ ವೇಗವಾದ ದಾರಿ.
ನೀಡುವಿಕೆ ನೀತಿಯನ್ನು ಸರಿಪಡಿಸಿ, ಪರಿಶೀಲನೆ ಕರೆಯನ್ನಲ್ಲ
ಶಾಶ್ವತ ಪರಿಹಾರವೆಂದರೆ ಅದು ಸೇವೆ ಸಲ್ಲಿಸಬೇಕಾದ ಉದ್ದೇಶಗಳನ್ನು ಅನುಮತಿಸುವ ನೀತಿಯ ಅಡಿಯಲ್ಲಿ ನೀಡಲಾದ ಮಧ್ಯವರ್ತಿ ಪ್ರಮಾಣಪತ್ರ, ಮತ್ತು ನಿರ್ಬಂಧವನ್ನು ಬರೆದು ಪರಿಶೀಲಿಸಲಾಗಿದೆ. ಪ್ರತಿ ಪ್ರಾಧಿಕಾರಕ್ಕೂ ಪ್ರತಿ ಉದ್ದೇಶವನ್ನು ಸೇರಿಸುವುದು ನೀತಿಯಲ್ಲ; ಅದು ವಿಸ್ತರಣೆಗೆ ಅರ್ಥ ನೀಡಿದ ನಿರ್ಬಂಧವನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ, ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ ಅದನ್ನು ಪ್ರೇರೇಪಿಸಿದ ಘಟನೆಗಿಂತ ಹೆಚ್ಚು ಕಾಲ ಉಳಿಯುತ್ತದೆ. ಪ್ರಾಧಿಕಾರವು ಯಾವ ಪಾತ್ರಗಳನ್ನು ಪ್ರಮಾಣೀಕರಿಸಬಹುದು ಎಂಬುದನ್ನು ವಿವರಿಸುವ ಸಣ್ಣ ಟಿಪ್ಪಣಿ ಪ್ರೊಫೈಲ್ನಲ್ಲಿದ್ದರೆ ಮುಂದಿನ ಮರುನೀಡುವಿಕೆ ಅದೇ ಚರ್ಚೆಯನ್ನು ಪುನರಾವರ್ತಿಸುವುದನ್ನು ತಡೆಯುತ್ತದೆ.
ಪರಿಶೀಲನೆಯನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುವುದು ಇನ್ನೊಂದು ಪ್ರಲೋಭನೆಯ ಶಾರ್ಟ್ಕಟ್, ಮತ್ತು ಅದು ಪ್ರಮಾಣಪತ್ರ ಸಮಸ್ಯೆಯನ್ನು ವಿಶ್ವಾಸ ಸಮಸ್ಯೆಯಾಗಿ ಪರಿವರ್ತಿಸುತ್ತದೆ. ಉದ್ದೇಶ ಪರಿಶೀಲನೆಯನ್ನು ಜಾಗದಲ್ಲೇ ಇರಿಸಿ, ಸರಪಳಿಯನ್ನು ಸರಿಪಡಿಸಿ ಮತ್ತು ಮಾರ್ಗವು ಈಗ ಉದ್ದೇಶಿತ ಪಾತ್ರಕ್ಕೆ ಸೇವೆ ಸಲ್ಲಿಸುತ್ತದೆ ಎಂದು ದೃಢೀಕರಿಸಲು ಅದೇ ಆಫ್ಲೈನ್ ಪರಿಶೀಲನೆಯನ್ನು ಮತ್ತೆ ಚಲಾಯಿಸಿ, ನಂತರ ಸೇವೆಯನ್ನು ಮತ್ತೆ ಸ್ಪರ್ಶಿಸಿ.