ರದ್ದುಗೊಳಿಸಿದ VPN ಪ್ರಮಾಣಪತ್ರ ಇನ್ನೂ ಸಂಪರ್ಕಗೊಳ್ಳುತ್ತಿದೆಯೇ? CRL ಜಾರಿಯನ್ನು ಪರಿಶೀಲಿಸಿ
ರದ್ದುಗೊಳಿಸಿದ ಪ್ರಮಾಣಪತ್ರಗಳು CRL ಪರಿಶೀಲಕರನ್ನು ತಲುಪದಿದ್ದಾಗ ಇನ್ನೂ ಸಂಪರ್ಕಗೊಳ್ಳುತ್ತವೆ. ಈ ಕ್ರಮದಲ್ಲಿ ನೀಡುಗರನ್ನು, ಲೋಡ್ ಆದ ಕ್ರಮ ಸಂಖ್ಯೆ, ಮರುಲೋಡ್ ವರ್ತನೆ ಮತ್ತು ಸಕ್ರಿಯ ಸೆಷನ್ಗಳನ್ನು ಪರಿಶೀಲಿಸಿ.
ನೀವು ಪ್ರಮಾಣಪತ್ರವನ್ನು ರದ್ದುಗೊಳಿಸಿದಿರಿ, ಹೊಸ ಪಟ್ಟಿ ರಚಿಸಿದಿರಿ, ಮತ್ತು ಹಳೆಯ ಪ್ರೊಫೈಲ್ ಇನ್ನೂ ಸುರಂಗವನ್ನು ಎಬ್ಬಿಸುತ್ತದೆ. ರದ್ದುಗೊಳಿಸುವಿಕೆ ಸ್ವತಃ ಮುರಿದಿಲ್ಲ: CRL ಎಂಬುದು ಕ್ರಮ ಸಂಖ್ಯೆ ಇನ್ನು ಮಾನ್ಯವಲ್ಲ ಎಂಬ ಸಹಿ ಮಾಡಿದ ಘೋಷಣೆ, ಮತ್ತು TLS ಅನ್ನು ಮುಗಿಸುವ ಘಟಕವು ಅದನ್ನು ಸರಿಯಾದ ನೀಡುಗರಿಗೆ ಲೋಡ್ ಮಾಡಿದಾಗ, ಸ್ವೀಕಾರ ನಿರ್ಣಯ ತೆಗೆದುಕೊಳ್ಳುವ ಮೊದಲೇ ಪ್ರವೇಶವನ್ನು ಬದಲಿಸುತ್ತದೆ. ಇಂತಹ ಹೆಚ್ಚಿನ ಪ್ರಕರಣಗಳು ಅಲ್ಲಿಯೇ ಇವೆ, ಆದ್ದರಿಂದ ರದ್ದುಗೊಳಿಸುವಿಕೆ ಮತ್ತು ನಿರಾಕರಣೆ ಎರಡು ಬೇರೆ ಬೇರೆ ಸತ್ಯಗಳು.
ಕೆಳಗಿನ ಐದು ಪರಿಶೀಲನೆಗಳನ್ನು ಕ್ರಮವಾಗಿ ಮಾಡಿ ಮತ್ತು ಮೊದಲ ವಿಫಲತೆಯಲ್ಲಿ ನಿಲ್ಲಿಸಿ, ಏಕೆಂದರೆ ಪ್ರತಿ ಮುಂದಿನ ಪರಿಶೀಲನೆಯು ಹಿಂದಿನವು ಸರಿ ಎಂದು ಊಹಿಸುತ್ತದೆ.
ಯಾವ ಘಟಕ ಸ್ವೀಕಾರ ನಿರ್ಣಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಎಂದು ಪರಿಶೀಲಿಸಿ
ಕ್ಲೈಂಟ್ ಪ್ರಮಾಣಪತ್ರವನ್ನು ಪರಿಶೀಲಿಸುವ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಹೆಸರಿಸಿ, ಏಕೆಂದರೆ ಆ ಪ್ರಕ್ರಿಯೆ ಮಾತ್ರ ಪಟ್ಟಿಯನ್ನು ಜಾರಿಗೊಳಿಸಬಲ್ಲದು. OpenVPN ಸರ್ವರ್ನಲ್ಲಿ ಅದು ಡೀಮನ್ ಸ್ವತಃ, crl-verify ನೊಂದಿಗೆ ಸಂರಚಿಸಲಾಗಿದೆ. ocserv ನಲ್ಲಿ ಅದು ocserv.conf ನಲ್ಲಿನ crl ಸಾಲು. strongSwan ನಲ್ಲಿ ಇನ್ಪುಟ್ಗಳು ಲೋಡ್ ಆದ CRL ಗಳು strictcrlpolicy ಜೊತೆಗೆ. VPN ಮುಂದೆ TLS ಮುಗಿಸುವ ಪ್ರಾಕ್ಸಿ ಅಥವಾ ಸಾಧನವೂ ನಿಜವಾದ ಪರಿಶೀಲಕರಾಗಿರಬಹುದು, ಹಾಗಿದ್ದರೆ ಅದರ ಹಿಂದಿನ ಡೀಮನ್ ಕ್ಲೈಂಟ್ ಪ್ರಮಾಣಪತ್ರವನ್ನು ಎಂದಿಗೂ ನೋಡುವುದಿಲ್ಲ.
WireGuard ಬೇರೆ ವರ್ಗಕ್ಕೆ ಸೇರುತ್ತದೆ. ಅದಕ್ಕೆ ಪ್ರಮಾಣಪತ್ರಗಳಿಲ್ಲ ಮತ್ತು ರದ್ದತಿ ಪಟ್ಟಿಯಿಲ್ಲ; ಪೀರ್ ಸಂರಚನೆಯಲ್ಲಿ ಅದರ ಸಾರ್ವಜನಿಕ ಕೀಲಿಯಿಂದ ಸ್ವೀಕರಿಸಲಾಗುತ್ತದೆ, ಆದ್ದರಿಂದ ಪ್ರವೇಶವನ್ನು ಮುಗಿಸುವುದು ಎಂದರೆ ಆ ಕೀಲಿಯನ್ನು ತೆಗೆಯುವುದು. WireGuard ಮಾತ್ರ ಇರುವ ನಿಯೋಜನೆಯಲ್ಲಿ CRL ಹುಡುಕುತ್ತಿದ್ದರೆ, ಆ ಕಾರ್ಯವಿಧಾನ ಅಲ್ಲಿ ಇಲ್ಲ.
ಕ್ಲೈಂಟ್ ಬದಿಯ ಬಲೆಗೂ ಎಚ್ಚರವಾಗಿರಿ. ಸರ್ವರ್ನ ಪ್ರಮಾಣಪತ್ರ ಇಷ್ಟವಾಗದ ಕಾರಣ ಸಂಪರ್ಕಕ್ಕೆ ನಿರಾಕರಿಸುವ ಕ್ಲೈಂಟ್ ಸರ್ವರ್ನ ಸರಪಣಿಯನ್ನು ಜಾರಿಗೊಳಿಸುತ್ತಿದೆ, ತನ್ನದೇ ರುಜುವಾತುಗಳನ್ನು ರದ್ದುಗೊಳಿಸುತ್ತಿಲ್ಲ. ಬಳಕೆದಾರ ಪ್ರಮಾಣಪತ್ರವು ಆ ಪ್ರಮಾಣಪತ್ರವನ್ನು ಪರಿಶೀಲಿಸುವಲ್ಲಿಯೇ ರದ್ದಾಗುತ್ತದೆ, ಮತ್ತು ಅದು ಬಹುತೇಕ ಯಾವಾಗಲೂ ಸರ್ವರ್ ಬದಿ.
ಪಟ್ಟಿಯನ್ನು ಯಾವ ನೀಡುಗರಿಗಾಗಿ ಸಹಿ ಮಾಡಲಾಗಿದೆ ಎಂದು ಪರಿಶೀಲಿಸಿ
CRL ಒಂದೇ ನೀಡುವ CA ಗೆ ಸೀಮಿತ. ಮೂಲ ಮತ್ತು ಮಧ್ಯವರ್ತಿ CA ಇದ್ದರೆ ಎಲೆ ಪ್ರಮಾಣಪತ್ರಗಳು ಮಧ್ಯವರ್ತಿಯಿಂದ ಬರುತ್ತವೆ, ಆದ್ದರಿಂದ ಮುಖ್ಯವಾದ ಪಟ್ಟಿ ಮಧ್ಯವರ್ತಿಯ CRL; ಮೂಲದ ಪಟ್ಟಿ ಆ ಎಲೆಗಳ ಬಗ್ಗೆ ಏನೂ ಹೇಳುವುದಿಲ್ಲ. ತಪ್ಪು ಫೈಲ್ ಕಡೆ ತೋರಿಸುವ ಪರಿಶೀಲಕ ಅದನ್ನು ಸಂತೋಷದಿಂದ ಪಾರ್ಸ್ ಮಾಡುತ್ತದೆ, ಹೊಂದಿಕೆಯಾಗುವ ನಮೂದು ಸಿಗದೆ ಎಲ್ಲವನ್ನೂ ಸ್ವೀಕರಿಸುತ್ತದೆ.
ಡೀಮನ್ ಮುಟ್ಟುವ ಮೊದಲು ಜೋಡಿಯನ್ನು ದೃಢೀಕರಿಸಿ. ಪ್ರಮಾಣಪತ್ರದಲ್ಲಿನ ನೀಡುಗರು ಪಟ್ಟಿಯ subject ಗೆ ಹೊಂದಿಕೆಯಾಗಬೇಕು:
openssl x509 -in client.crt -noout -issuer -serial
openssl crl -in intermediate.crl -noout -issuer -lastupdate -nextupdateಎರಡೂ ಒಂದೇ CA ಯಿಂದ ಬಂದಾಗ, ಪ್ರಮಾಣಪತ್ರಕ್ಕೆ ಮುದ್ರಿಸಿದ ಕ್ರಮ ಸಂಖ್ಯೆಯೇ ಪಟ್ಟಿಯಲ್ಲಿ ಬರಬೇಕಾದ ಮೌಲ್ಯ. ಅವು ಹೊಂದಿಕೆಯಾಗದಿದ್ದರೆ, ನಿಮ್ಮಲ್ಲಿ ತಪ್ಪು CRL ಅಥವಾ ಅದರ ತಪ್ಪು ಪ್ರತಿ ಇದೆ.
ಸಿಂಧುತ್ವ ಅದೇ ಪರಿಶೀಲನೆಗೆ ಸೇರಿದೆ. ಹಿಂದಿನ nextUpdate ಪಟ್ಟಿಯನ್ನು ಹಳೆಯದಾಗಿಸುತ್ತದೆ, ಮತ್ತು ಮುಚ್ಚಿದ ರೀತಿಯಲ್ಲಿ ವಿಫಲವಾಗುವ ಪರಿಶೀಲಕ ಆಗ ರದ್ದಾದದನ್ನು ಮಾತ್ರವಲ್ಲದೆ ಪ್ರತಿ ಕ್ಲೈಂಟ್ ಅನ್ನು ನಿರಾಕರಿಸುತ್ತದೆ.
ಕ್ರಮ ಸಂಖ್ಯೆ ಡೀಮನ್ ಲೋಡ್ ಮಾಡಿದ ಪ್ರತಿಯಲ್ಲಿ ಇದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ
ರದ್ದುಗೊಳಿಸುವಿಕೆ CA ಡೇಟಾಬೇಸ್ನಲ್ಲಿ ನಮೂದು ಬರೆಯುತ್ತದೆ, ಮತ್ತು ಮರುಉತ್ಪಾದನೆ ಹೊಸ ಫೈಲ್ ಬರೆಯುತ್ತದೆ. ಎರಡರಲ್ಲಿ ಯಾವುದೂ ಪ್ರಾರಂಭದಲ್ಲಿ ಹಳೆಯ ಪ್ರತಿಯನ್ನು ಲೋಡ್ ಮಾಡಿದ ಚಾಲನೆಯಲ್ಲಿರುವ ಡೀಮನ್ ತಲುಪುವುದಿಲ್ಲ. ಪಟ್ಟಿಯನ್ನು ಡಂಪ್ ಮಾಡಿ ಕ್ರಮ ಸಂಖ್ಯೆ ಹುಡುಕಿ:
openssl crl -in intermediate.crl -noout -text | grep -i -A2 'Serial Number'
openssl ca -revoke client.crt
openssl ca -gencrl -out intermediate.crlನಂತರ ನಿಮ್ಮ ಅನುಷ್ಠಾನ ಫೈಲ್ ಅನ್ನು ಹೇಗೆ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಎಂದು ಪರಿಶೀಲಿಸಿ. OpenVPN crl-verify ಗೆ ನೀಡಿದ ಮಾರ್ಗವನ್ನು ಪ್ರಾರಂಭದಲ್ಲಿ ಒಮ್ಮೆ ಓದುತ್ತದೆ, ಆದ್ದರಿಂದ ಹೊಸ ಪಟ್ಟಿಗೆ ಮರುಪ್ರಾರಂಭ ಅಥವಾ ಮರುಪ್ರಾರಂಭ ಸಂಕೇತ ಬೇಕು; ಅದೇ ಆಯ್ಕೆ ಯಾವುದೇ ಡೈರೆಕ್ಟರಿಗೆ ತೋರಿಸಿದರೆ ಪ್ರತಿ ಸಂಪರ್ಕಕ್ಕೂ ಮತ್ತೆ ಓದಲಾಗುತ್ತದೆ, ಆದ್ದರಿಂದ ಡೈರೆಕ್ಟರಿ ಮೋಡ್ ಇದೆ. strongSwan ತನ್ನ ರುಜುವಾತುಗಳನ್ನು ಮರುಲೋಡ್ ಮಾಡಿಕೊಳ್ಳಬೇಕು, ಉದಾಹರಣೆಗೆ swanctl --load-creds ನೊಂದಿಗೆ. ಫೈಲ್ ಡಿಸ್ಕ್ನಲ್ಲಿ ಸರಿಯಾಗಿರುವುದು ಮತ್ತು ಪರಿಶೀಲಕ ಅದನ್ನು ಬಳಸುವುದು ಎರಡು ಬೇರೆ ಸತ್ಯಗಳು.
ಕಾಣೆಯಾದ ಅಥವಾ ಅವಧಿ ಮುಗಿದ ಪಟ್ಟಿಯ ನೀತಿಯನ್ನು ಪರಿಶೀಲಿಸಿ
ಇದು ಅನೇಕ ನಿಯೋಜನೆಗಳು ಎಂದಿಗೂ ಸ್ಪಷ್ಟವಾಗಿ ತೆಗೆದುಕೊಳ್ಳದ ನಿರ್ಣಯ, ಮತ್ತು ರದ್ದುಗೊಳಿಸುವಿಕೆ ನಿಮ್ಮನ್ನು ರಕ್ಷಿಸುತ್ತದೆಯೇ ಅಥವಾ ಎಲ್ಲರನ್ನೂ ಹೊರಗೆ ಲಾಕ್ ಮಾಡುತ್ತದೆಯೇ ಎಂದು ನಿರ್ಧರಿಸುತ್ತದೆ. Fail-closed ಎಂದರೆ ಬಳಸಬಹುದಾದ ರದ್ದತಿ ಮಾಹಿತಿ ಇಲ್ಲದೆ ನಿರಾಕರಣೆ ಸಂಭವಿಸುತ್ತದೆ; fail-open ಎಂದರೆ ಪರಿಶೀಲಕ ಅದಿಲ್ಲದೆ ಮುಂದುವರಿಯುತ್ತದೆ. strongSwan ಆಯ್ಕೆಯನ್ನು strictcrlpolicy ಆಗಿ ತೋರಿಸುತ್ತದೆ. OpenVPN crl-verify ನೊಂದಿಗೆ ಓದಲು ಅಥವಾ ಪಾರ್ಸ್ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲದ ಫೈಲ್ನಲ್ಲಿ ಪ್ರಾರಂಭವಾಗಲು ನಿರಾಕರಿಸುತ್ತದೆ, ಮತ್ತು ಅವಧಿ ಮುಗಿದ ಪಟ್ಟಿ ಮೌನ ಸ್ವೀಕಾರದ ಬದಲು ಅವಧಿ ಮುಗಿದ CRL ಬಗ್ಗೆ TLS ಪರಿಶೀಲನಾ ದೋಷವಾಗಿ ಕಾಣಿಸುತ್ತದೆ.
| State of the revocation data | Fail-closed result | Fail-open result |
|---|---|---|
| List missing or unreadable | Verification fails, so expect an outage | Every client connects, including the revoked one |
List past nextUpdate | Validation errors until a fresh list is deployed | Old status is trusted indefinitely |
| Revoked serial present in the loaded list | Handshake rejected for that certificate | Handshake rejected for that certificate |
ನೀವು ಯಾವ ದಿಕ್ಕನ್ನೂ ಆರಿಸಿದರೂ, ಸ್ವಯಂಚಾಲನೆ ಆಯ್ಕೆಗಿಂತ ಮುಖ್ಯ: CRL ಅನ್ನು nextUpdate ಮೊದಲು ಮರುಉತ್ಪಾದಿಸುವ ಕೆಲಸ, ಮತ್ತು ನಿಯೋಜಿತ ಪ್ರತಿ ಹಳೆಯದಾದಾಗ ಎಚ್ಚರಿಕೆ, ಎರಡೂ ನೀತಿಗಳು ಘಟನೆಯಾಗುವುದನ್ನು ತಡೆಯುತ್ತವೆ. OCSP ನೊಂದಿಗೆ ಆನ್ಲೈನ್ ಪರಿಶೀಲನೆ ತಾಜಾತನವನ್ನು ಪ್ರತಿಸ್ಪಂದಕರಿಗೆ ಸರಿಸುತ್ತದೆ, ಆದರೆ ಅದೇ ನಿಯಮ ಅನ್ವಯಿಸುತ್ತದೆ, ಏಕೆಂದರೆ ಉತ್ತರವನ್ನು ಪರಿಶೀಲಿಸಲು ಸಂರಚಿಸದ ಪರಿಶೀಲಕ ಏನನ್ನೂ ಬದಲಿಸುವುದಿಲ್ಲ.
ಸಕ್ರಿಯ ಸೆಷನ್, ನಂತರ ಕೀಲಿಯ ಪ್ರತಿಗಳನ್ನು ಪರಿಶೀಲಿಸಿ
ರದ್ದುಗೊಳಿಸುವಿಕೆಯನ್ನು ಪ್ರಮಾಣಪತ್ರ ಪರಿಶೀಲನೆಯ ಸಮಯದಲ್ಲಿ ಮೌಲ್ಯಮಾಪನ ಮಾಡಲಾಗುತ್ತದೆ, ಅದು ಸಂಪರ್ಕಿಸುವಾಗ ಮತ್ತು ಮರುಸಂಧಾನದ ಸಮಯದಲ್ಲಿ ನಡೆಯುತ್ತದೆ. ಸ್ಥಾಪಿತ ಸೆಷನ್ ಮರುಸಂಧಾನ ಮಾಡುವವರೆಗೆ ಮುಂದುವರಿಯುತ್ತದೆ, ಮತ್ತು OpenVPN ನ ಡೀಫಾಲ್ಟ್ reneg-sec 3600 ನೊಂದಿಗೆ ಗಂಟೆಗೊಮ್ಮೆ. ವ್ಯಕ್ತಿ ಈಗಲೇ ನೆಟ್ವರ್ಕ್ನಿಂದ ಹೊರಗೆ ಹೋಗಬೇಕಿದ್ದರೆ, ಪಟ್ಟಿ ಪ್ರಕಟಿಸುವುದರ ಜೊತೆಗೆ ಸೆಷನ್ ಅನ್ನೂ ಮುಗಿಸಿ, ನಂತರ ಮರುಸಂಪರ್ಕ ನಿರಾಕರಿಸಲ್ಪಡುತ್ತದೆ ಎಂದು ದೃಢೀಕರಿಸಿ.
ರುಜುವಾತುಗಳನ್ನು ಅವುಗಳ ಪ್ರತಿಗಳಿಂದ ಬೇರ್ಪಡಿಸಿ. ಒಂದು ಲ್ಯಾಪ್ಟಾಪ್ನಲ್ಲಿ ಪ್ರೊಫೈಲ್ ಅಳಿಸುವುದು ಅದೇ ಖಾಸಗಿ ಕೀಲಿಯ ಇನ್ನೊಂದು ಪ್ರತಿ ದೃಢೀಕರಣಗೊಳ್ಳುವುದನ್ನು ತಡೆಯುವುದಿಲ್ಲ; ರದ್ದುಗೊಳಿಸುವಿಕೆಯೇ ಪ್ರತಿ ಪ್ರತಿಯನ್ನೂ ನಿಷ್ಪ್ರಯೋಜಕಗೊಳಿಸುತ್ತದೆ, ಅದೂ ಹಿಂದಿನ ಪರಿಶೀಲನೆಗಳು ಸರಿಯಾದಾಗ ಮಾತ್ರ. ಬದಲಿ ಸಾಧನಕ್ಕೆ ಅದರದೇ ಪ್ರಮಾಣಪತ್ರ ನೀಡಿ, ಒಂದನ್ನು ಇನ್ನೊಂದನ್ನು ಮುಟ್ಟದೆ ರದ್ದುಗೊಳಿಸಬಹುದಾಗಲಿ.
ಇದನ್ನು ಪೂರ್ಣ ಎಂದು ಹೇಳುವ ಮೊದಲು: ಪರಿಶೀಲಿಸುವ ಘಟಕ ಗುರುತಿಸಲಾಗಿದೆ, ಪಟ್ಟಿಯ ನೀಡುಗರು ಎಲೆಯ ನೀಡುಗರೊಂದಿಗೆ ಹೊಂದಿಕೆಯಾಗುತ್ತದೆ, ರದ್ದಾದ ಕ್ರಮ ಸಂಖ್ಯೆ ಡೀಮನ್ ನಿಜವಾಗಿ ಲೋಡ್ ಮಾಡಿದ ಪ್ರತಿಯಲ್ಲಿ ಇದೆ, ಕಾಣೆಯಾದ ಅಥವಾ ಅವಧಿ ಮುಗಿದ ಪಟ್ಟಿಗಳ ನೀತಿ ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿದೆ ಮತ್ತು ಮೇಲ್ವಿಚಾರಣೆಯಲ್ಲಿದೆ, ಮತ್ತು ಸಕ್ರಿಯ ಸೆಷನ್ ಕಾಯುವ ಬದಲು ಮುಗಿಸಲಾಗಿದೆ. ಇವೆಲ್ಲದರ ಹಿಂದಿನ ಸ್ವರೂಪಗಳು RFC 5280 ನಲ್ಲಿ ನಿರ್ದಿಷ್ಟಪಡಿಸಲಾಗಿವೆ.