OCSP ಮತ್ತು CRL: ಪ್ರತಿ ರದ್ದತಿ ಪರಿಶೀಲನೆ ನಿಜವಾಗಿ ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ

ಈ ಎರಡು ರದ್ದತಿ ಪರಿಶೀಲನೆಗಳಲ್ಲಿ ಒಂದು ಒಂದೇ ಪ್ರಮಾಣಪತ್ರದ ಬಗ್ಗೆ ಸಹಿ ಮಾಡಿದ ಉತ್ತರವನ್ನು ನೀಡುತ್ತದೆ, ಇನ್ನೊಂದು ನೀವು ಪೂರ್ಣವಾಗಿ ಡೌನ್ಲೋಡ್ ಮಾಡುವ ಸಹಿ ಮಾಡಿದ ಪಟ್ಟಿಯನ್ನು ನೀಡುತ್ತದೆ. ಎರಡೂ ಕೂಡ ಒಂದು ರುಜುವಾತು ಇನ್ನೂ ವಿಶ್ವಾಸಾರ್ಹವೇ ಎಂದು ಪರಿಶೀಲಕನಿಗೆ ತಿಳಿಸಲು ಉದ್ದೇಶಿಸಿವೆ, ಮತ್ತು ಎರಡೂ ಒಂದಕ್ಕೊಂದು ಸ್ವಲ್ಪವೂ ಹೋಲದ ರೀತಿಯಲ್ಲಿ ವಿಫಲವಾಗುತ್ತವೆ. ಕೆಳಗಿನ ಕ್ರಮವು ನಿರ್ವಾಹಕನಿಗೆ ಉತ್ಪಾದನೆಯಲ್ಲಿ ನಿಜವಾಗಿ ಎದುರಾಗುವುದನ್ನು ಅನುಸರಿಸುತ್ತದೆ, ತಂತಿಯ ಮೇಲಿನ ಬೈಟ್ಗಳಿಂದ ಆರಂಭಿಸಿ ಸಂಪರ್ಕವನ್ನು ನಿರಾಕರಿಸುವ ಗೇಟ್ವೇವರೆಗೆ. ಒಂದು ಹಂತವನ್ನು ಬಿಟ್ಟುಬಿಡುವುದು, ನಿಯೋಜನೆಯು ಕಾಗದದ ಮೇಲೆ ಮಾತ್ರ ಇರುವ ರದ್ದತಿ ನೀತಿಯೊಂದಿಗೆ ಉಳಿಯುವ ದಾರಿ.

ಹಂತ 1: ಪ್ರತಿ ಪರಿಶೀಲನೆ ಏನನ್ನು ನೀಡುತ್ತದೆ ಮತ್ತು ಎಷ್ಟು ಕಾಲ ಬಳಸಲು ಯೋಗ್ಯವಾಗಿರುತ್ತದೆ

CRL ಅನ್ನು ಒಂದು ಸಹಿ ಮಾಡಿದ ವಸ್ತುವಾಗಿ ಪ್ರಕಟಿಸಲಾಗುತ್ತದೆ, ಅದು ನೀಡುವವನು ರದ್ದು ಮಾಡಿದ ಪ್ರತಿ ಪ್ರಮಾಣಪತ್ರವನ್ನೂ ಆವರಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಪರಿಶೀಲಕ ಅದನ್ನು ಒಮ್ಮೆ ಪಡೆದು ಪಟ್ಟಿಯ nextUpdate ಮುಗಿಯುವವರೆಗೆ ಮತ್ತೆ ಬಳಸುತ್ತಾನೆ. OCSP ಪ್ರತಿಕ್ರಿಯೆ ಹೆಚ್ಚು ಸಂಕುಚಿತ: ಅದು ನಿಖರವಾಗಿ ಒಂದು ಪ್ರಮಾಣಪತ್ರಕ್ಕೆ ಉತ್ತರಿಸುತ್ತದೆ ಮತ್ತು thisUpdate, producedAt ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ nextUpdate ಅನ್ನೂ ಒಳಗೊಂಡಿರುತ್ತದೆ. ಆ ವ್ಯತ್ಯಾಸವೇ ಉಳಿದೆಲ್ಲವನ್ನೂ ನಿರ್ದೇಶಿಸುತ್ತದೆ. ಕ್ಯಾಶ್ ಮಾಡಿದ CRL ಮೌನವಾಗಿ ಹಳೆಯದಾಗುತ್ತದೆ, ಕಾರಣ ಫೈಲ್ ಇನ್ನೂ ವಿಶ್ಲೇಷಣೆಯಾಗುತ್ತದೆ ಮತ್ತು ಅದರ ಸಹಿ ಇನ್ನೂ ಪರಿಶೀಲನೆಯಾಗುತ್ತದೆ, ಆದರೆ ಅವಧಿ ಮುಗಿದ OCSP ಪ್ರತಿಕ್ರಿಯೆ ಅದರ ಸಮಯ ಚಿಹ್ನೆಗಳನ್ನು ಓದಿದ ಕ್ಷಣವೇ ಸ್ಪಷ್ಟವಾಗಿ ಮೌಲ್ಯಹೀನವಾಗಿರುತ್ತದೆ.

ಆದ್ದರಿಂದ ಕ್ಯಾಶಿಂಗ್ ಮೊದಲು ನಿರ್ಧರಿಸಬೇಕಾದದ್ದು: ಯಾವ ಘಟಕ ನಕಲನ್ನು ಇಟ್ಟುಕೊಳ್ಳುತ್ತದೆ, ಮತ್ತು ಆ ನಕಲು ಯಾವ ಮೇಲ್ಪರಿಮಿತಿಯನ್ನು ಪಾಲಿಸುತ್ತದೆ. ಗೇಟ್ವೇನಲ್ಲಿ ಮೇಲ್ಪರಿಮಿತಿ nextUpdate ಮೈನಸ್ ಸುರಕ್ಷತಾ ಅಂಚು ಆಗಿರಬೇಕು, ಎಂದಿಗೂ HTTP ಕ್ಯಾಶ್ ಶೀರ್ಷಿಕೆ ಆಕಸ್ಮಿಕವಾಗಿ ಸೂಚಿಸುವುದಲ್ಲ. openssl crl -in issuer.crl -noout -lastupdate -nextupdate ಎರಡೂ ದಿನಾಂಕಗಳನ್ನು ಮುದ್ರಿಸುತ್ತದೆ, ಮತ್ತು nextUpdate ಈಗಾಗಲೇ ಹಿಂದಿನದಾಗಿರುವ ಪಟ್ಟಿಯನ್ನು ಕೇವಲ ಹಳೆಯದು ಎಂದಲ್ಲ, ಕಾಣೆಯಾದುದು ಎಂದು ಪರಿಗಣಿಸಬೇಕು.

ಹಂತ 2: ಪ್ರಮಾಣಪತ್ರವು ಕ್ಲೈಂಟ್ ಅನ್ನು ಎಲ್ಲಿಗೆ ನಿರ್ದೇಶಿಸುತ್ತದೆ

ಎಲೆ ಪ್ರಮಾಣಪತ್ರ ಸಾಮಾನ್ಯವಾಗಿ ಎರಡು ಸುಳಿವುಗಳನ್ನು ಹೊಂದಿರುತ್ತದೆ: CRL ವಿತರಣಾ ಬಿಂದು ವಿಸ್ತರಣೆ ಮತ್ತು OCSP ಗಾಗಿ ಪ್ರಾಧಿಕಾರ ಮಾಹಿತಿ ಪ್ರವೇಶ ನಮೂದು. openssl x509 -in client.pem -noout -ext crlDistributionPoints ಮೊದಲನೆಯದನ್ನು ಮುದ್ರಿಸುತ್ತದೆ, ಮತ್ತು ಎರಡನೆಯದು openssl x509 -in client.pem -noout -text ನ AIA ವಿಭಾಗದ ಅಡಿಯಲ್ಲಿದೆ. ಯಾವುದೇ ವಿಸ್ತರಣೆ ಸೂಚಕವೇ ಹೊರತು ಬಾಧ್ಯತೆಯಲ್ಲ. ರದ್ದತಿ ಪರಿಶೀಲನೆಯನ್ನು ಎಂದಿಗೂ ಜಾರಿಗೊಳಿಸದ ಕ್ಲೈಂಟ್, ಒಂದು ವರ್ಷದಿಂದ ಸತ್ತಿರುವ ಪ್ರತಿಸ್ಪಂದಕನನ್ನು ಹೆಸರಿಸುವ ವಿಸ್ತರಣೆಗಳನ್ನು ಹೊಂದಿರುವ ಪ್ರಮಾಣಪತ್ರಕ್ಕೆ ಸಂಪೂರ್ಣವಾಗಿ ಚೆನ್ನಾಗಿ ಸಂಪರ್ಕಗೊಳ್ಳುತ್ತದೆ.

ವಿತರಣಾ ಬಿಂದುಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಒಂದೇ ಜಾಲಬಂಧ ವಿಭಾಗದ ಒಳಗೆ ಮಾತ್ರ ಪರಿಹರಿಸಲ್ಪಡುವ ಆಂತರಿಕ ಹೋಸ್ಟ್ ಅನ್ನು ಹೆಸರಿಸುತ್ತವೆ, ಮತ್ತು ಕೆಲವು ಹಳೆಯ ಕ್ಲೈಂಟ್ಗಳು ldap URLಗಳನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ನಿರಾಕರಿಸುತ್ತವೆ. ತಲುಪುವಿಕೆಯನ್ನು ಸುರಂಗವನ್ನು ಮುಗಿಸುವ ಹೋಸ್ಟ್ನಿಂದ ಪರೀಕ್ಷಿಸಿ, ನಿಮ್ಮ ಸ್ವಂತ ಲ್ಯಾಪ್ಟಾಪ್ನಿಂದ ಅಲ್ಲ, ಏಕೆಂದರೆ ಅದರ ವೈಫಲ್ಯ ನಿಜವಾಗಿ ಮುಖ್ಯವಾಗುವ ಏಕೈಕ ದೃಷ್ಟಿಕೋನ ಅದೇ.

ಹಂತ 3: ಅಡಚಣೆಗೆ ಮೊದಲು fail-closed ಅಥವಾ fail-open ಆಯ್ಕೆಮಾಡಿ

ತಲುಪಲಾಗದ ಪ್ರತಿಸ್ಪಂದಕ ಅಥವಾ ಅವಧಿ ಮುಗಿದ ಪಟ್ಟಿ ನಿರ್ಧಾರವನ್ನು ಒತ್ತಾಯಿಸುತ್ತದೆ: ಸಂಪರ್ಕವನ್ನು ನಿರಾಕರಿಸಿ, ಅಥವಾ ಒಪ್ಪಿಕೊಂಡು ಕೊರತೆಯನ್ನು ದಾಖಲಿಸಿ. OpenSSL ನ verify ಉಪಆದೇಶವು ಕಟ್ಟುನಿಟ್ಟಿನ ಆಯ್ಕೆಯನ್ನು ಸ್ಪಷ್ಟಗೊಳಿಸುತ್ತದೆ, ಏಕೆಂದರೆ -crl_check ಸೇರಿಸಿದರೆ ಲಭ್ಯವಿಲ್ಲದ CRL unable to get certificate CRL ಮತ್ತು ವಿಫಲ ಪರಿಶೀಲನೆಯಾಗುತ್ತದೆ. ಹೆಚ್ಚಿನ ಸ್ಟಾಕ್ಗಳಲ್ಲಿ ಮೃದು ವೈಫಲ್ಯ ಯಾವುದೇ ಧ್ವಜವಲ್ಲ, ಅದು ಪರಿಶೀಲನೆಯ ಅನುಪಸ್ಥಿತಿ, ಮತ್ತು ಅದಕ್ಕಾಗಿಯೇ ಅದು ಆಕಸ್ಮಿಕವಾಗಿ ಹಡಗು ಸೇರುತ್ತದೆ.

ಕ್ಲೈಂಟ್ ನಿಜವಾಗಿ ಯಾವ ವರ್ತನೆ ಹೊಂದಿದೆ ಎಂದು ನೋಡಲು ಪ್ರತಿಸ್ಪಂದಕವನ್ನು ತೆಗೆದು ಮತ್ತೆ ಸಂಪರ್ಕಿಸಿ. ಸುರಂಗವು ಇನ್ನೂ ಮೇಲೆ ಬಂದರೆ, ಬಿಟ್ಟುಬಿಟ್ಟ ಪರಿಶೀಲನೆಯನ್ನು ದಾಖಲಿಸಿದ ಲಾಗ್ ಸಾಲನ್ನು ಹುಡುಕಿ, ನಂತರ ಘಟನೆಯ ಸಮಯದಲ್ಲಿ ಯಾರಾದರೂ ಆ ಸಾಲನ್ನು ಓದುತ್ತಾರೆಯೇ ಎಂದು ಕೇಳಿ. ಒಂದೇ ಮಾರಾಟಗಾರ ಪ್ರೋಟೋಕಾಲ್ ಪ್ರಕಾರ ಭಿನ್ನವಾಗಬಹುದು: ಒಂದೇ ಯಂತ್ರದಲ್ಲಿ IKEv2 ಕ್ಲೈಂಟ್ ಮತ್ತು OpenVPN ಕ್ಲೈಂಟ್ ಸಂಬಂಧವಿಲ್ಲದ ಸಂರಚನಾ ಸೆಟ್ಟಿಂಗ್ಗಳನ್ನು ಓದುತ್ತವೆ.

ಹಂತ 4: ಸಂಚಾರವನ್ನು ಒಪ್ಪಿಕೊಳ್ಳುವಲ್ಲಿಯೇ ಪರಿಶೀಲನೆ ನಡೆಯುತ್ತದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸಿ

ಸಂಪರ್ಕವನ್ನು ಮುಗಿಸುವ ಅಥವಾ ಅಧಿಕಾರ ನೀಡುವ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಹುಡುಕಿ, ನಂತರ ರದ್ದತಿ ಪರಿಶೀಲನೆಯನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುವ ಸಂರಚನಾ ಸಾಲನ್ನು ಅದರಿಂದ ಕೇಳಿ. ಸರಪಳಿಯನ್ನು ಮಾನ್ಯಗೊಳಿಸುವ ಆದರೆ ರದ್ದತಿಯ ಬಗ್ಗೆ ಎಂದಿಗೂ ಕೇಳದ ಗೇಟ್ವೇ ನಿಮ್ಮ ದಾಖಲೆಗಳಲ್ಲಿರುವುದಕ್ಕಿಂತ ಬೇರೆ ನೀತಿಯನ್ನು ಜಾರಿಗೊಳಿಸುತ್ತದೆ, ಮತ್ತು ಪ್ರಮಾಣಪತ್ರ ಸರಪಳಿಯ ಯಾವುದೇ ಸ್ಕ್ರೀನ್ಶಾಟ್ ಅದಕ್ಕೆ ವಿರುದ್ಧವಾಗಿ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ. OpenVPN ಆಯ್ಕೆಯನ್ನು crl-verify ಎಂದು ಬರೆಯುತ್ತದೆ; strongSwan CRL ಮತ್ತು OCSP ಹುಡುಕಾಟಗಳನ್ನು CA ಸಂರಚನೆಯ ಅಡಿಯಲ್ಲಿ ಇಡುತ್ತದೆ, ಅಲ್ಲಿ crl_uris ಅಥವಾ ocsp_uris ಹೊಂದಿಸಲಾಗುತ್ತದೆ. ಎರಡರಲ್ಲಿ ಯಾವುದನ್ನೂ ತೋರಿಸಲಾಗದಿದ್ದರೆ, ಪರಿಶೀಲನೆ ಇಲ್ಲ ಎಂದು ಊಹಿಸಿ.

OCSP ಪ್ರತಿಕ್ರಿಯೆ ನೀಡುವ CA ಅದಕ್ಕೆ ಸಹಿ ಮಾಡಿದಾಗ ಮಾತ್ರ, ಅಥವಾ ಆ CA ನಿಯೋಜಿಸಿದ OCSPSigning ವಿಸ್ತೃತ ಕೀ ಬಳಕೆಯನ್ನು ಹೊಂದಿರುವ ಪ್ರತಿಸ್ಪಂದಕ ಸಹಿ ಮಾಡಿದಾಗ ಮಾತ್ರ ಮಾನ್ಯವಾಗಿರುತ್ತದೆ, ಆದ್ದರಿಂದ ಸಂಬಂಧವಿಲ್ಲದ ಸೇವೆಯಿಂದ ಬಂದ ಉತ್ತರ ಏನನ್ನೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ. ನೀವೇ ಪ್ರತಿಸ್ಪಂದಕವನ್ನು ನಡೆಸುತ್ತಿದ್ದರೆ, ಅದನ್ನು ಕಠಿಣ ಅವಲಂಬನೆಯಾಗಿ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಿ, ಏಕೆಂದರೆ ಒಂದು ಸತ್ತ ಸೇವೆ ಒಂದೇ ಬಾರಿಗೆ ಪ್ರತಿ fail-closed ಕ್ಲೈಂಟ್ಗೂ ಅಡಚಣೆಯಾಗುತ್ತದೆ.

ಹಂತ 5: ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಒಂದು ಪ್ರಮಾಣಪತ್ರವನ್ನು ರದ್ದು ಮಾಡಿ

ಪರೀಕ್ಷಾ ಪ್ರಮಾಣಪತ್ರವನ್ನು ತೆಗೆದುಕೊಳ್ಳಿ, ಉತ್ಪಾದನೆ ಬಳಸುವ ಅದೇ ಮಾರ್ಗದ ಮೂಲಕ ಅದನ್ನು ರದ್ದು ಮಾಡಿ, ಮತ್ತು ಪ್ರತಿಸ್ಪಂದಕನನ್ನು ನೇರವಾಗಿ ಕೇಳಿ. openssl ocsp -issuer ca.pem -cert old.pem -url http://ocsp.example.net -resp_text ರದ್ದತಿ ಸಮಯದೊಂದಿಗೆ Cert Status: revoked ಅನ್ನು ವರದಿ ಮಾಡಬೇಕು, ಮತ್ತು good ಉತ್ತರ ಎಂದರೆ ನಿಮ್ಮ ರದ್ದತಿ ನಿಮ್ಮ ಕ್ಲೈಂಟ್ಗಳು ಕೇಳುವ ಪ್ರತಿಸ್ಪಂದಕನನ್ನು ತಲುಪಿಲ್ಲ. ನಂತರ ಪಟ್ಟಿ ಮಾರ್ಗದಲ್ಲಿ ಅದೇ ನಿರ್ಧಾರವನ್ನು ನೋಡಲು openssl verify -crl_check -CRLfile issuer.crl -CAfile ca.pem old.pem ಚಲಾಯಿಸಿ. ನಿರ್ಗಮನ ಕೋಡ್ ಬದಲು ಕಾರಣದ ಸ್ಟ್ರಿಂಗ್ ಓದಿ, ಏಕೆಂದರೆ ರದ್ದತಿ ನಿರಾಕರಣೆ ಮತ್ತು ಸರಪಳಿ ದೋಷ ಎರಡೂ ವೈಫಲ್ಯದಲ್ಲಿ ಕೊನೆಗೊಳ್ಳುತ್ತವೆ.

ನಿಜವಾಗಿ ಮುಖ್ಯವಾದ ಹಂತ ಕೊನೆಯದು: ಹಳೆಯ ಪ್ರೊಫೈಲ್ನೊಂದಿಗೆ ನಿಜವಾದ ಜಾರಿ ಬಿಂದುವಿನ ಎದುರು ಮತ್ತೆ ಸಂಪರ್ಕಿಸಿ ಮತ್ತು ನಿರಾಕರಣೆ ರದ್ದತಿಯಿಂದಲೇ ಬರುತ್ತದೆ ಎಂದು ದೃಢೀಕರಿಸಿ. ನಂತರ ಹೊಸ, ಮಾನ್ಯ ಪ್ರಮಾಣಪತ್ರದೊಂದಿಗೆ ಮತ್ತೆ ಸಂಪರ್ಕಿಸಿ ನೀವು ಕೇವಲ ಶ್ರೋತೃವನ್ನು ಮುರಿದಿಲ್ಲ ಎಂದು ಸಾಬೀತುಪಡಿಸಿ. ಕ್ಲೈಂಟ್ನಲ್ಲಿ ಪ್ರೊಫೈಲ್ ಅನ್ನು ಅಳಿಸುವುದು ಸರ್ವರ್ನ ನಿರ್ಧಾರದ ಬಗ್ಗೆ ಏನನ್ನೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಸುರಂಗವನ್ನು ಎಂದಿಗೂ ಮುಗಿಸದ ಯಂತ್ರದಲ್ಲಿ openssl verify ಯಶಸ್ವಿಯಾಗಿ ಚಲಾಯಿಸುವುದೂ ಇಲ್ಲ. RFC 6960 ಅನುರೂಪ OCSP ಪ್ರತಿಕ್ರಿಯೆಯಲ್ಲಿ ಏನಿರುತ್ತದೆ ಎಂದು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತದೆ, ಈ ಪರೀಕ್ಷೆ ಓದುವ ಸ್ಥಿತಿ ಮೌಲ್ಯಗಳೂ ಸೇರಿದಂತೆ.