strongSwan: ಕೀ ಪ್ರಕಾರ, ಲೋಡರ್ ಮತ್ತು ತಪ್ಪು backend
PEM ಒಂದು ಕಂಟೇನರ್, ಕೀ ಪ್ರಕಾರವಲ್ಲ. ಪ್ರಮಾಣಪತ್ರದ ಸಾರ್ವಜನಿಕ ಕೀಯನ್ನು ಖಾಸಗಿ ಕೀಯೊಂದಿಗೆ ಹೋಲಿಸಿ, ನಂತರ ಅದನ್ನು ನಿಜವಾಗಿ ಓದುವ backend ಮೂಲಕ ಲೋಡ್ ಮಾಡಿ.
ಫೈಲ್ ವಿಸ್ತರಣೆಗಳು ಕೀ ಅಲ್ಗಾರಿದಮ್ಗಳನ್ನು ಗುರುತಿಸುವುದಿಲ್ಲ, ಮತ್ತು .pem ಹೊದಿಕೆಯಲ್ಲಿ RSA ಅಥವಾ ECDSA ವಸ್ತು ಇರಬಹುದು. PEM ಬೈಟ್ಗಳನ್ನು ಹೇಗೆ ಸುತ್ತುತ್ತದೆ ಎಂಬುದನ್ನು ವಿವರಿಸುತ್ತದೆ, ಆದರೆ RSA ಮತ್ತು ECDSA ಬೇರೆ ಬೇರೆ ಅಲ್ಗಾರಿದಮ್ಗಳ ಹೆಸರುಗಳು, ಮತ್ತು PKCS12 ಫೈಲ್ ಮೂರನೇ ವಿಷಯ. strongSwan ಪ್ಲಗಿನ್ಗಳು ಮತ್ತು ಸಂರಚನಾ backend ಮೂಲಕ ರುಜುವಾತುಗಳನ್ನು ಲೋಡ್ ಮಾಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಪ್ರಮಾಣಪತ್ರವು ಪಟ್ಟಿಯಲ್ಲಿ ಕಾಣಿಸಬಹುದು ಆದರೆ ಖಾಸಗಿ ಕೀ ಎಂದಿಗೂ ಬಳಸಲು ಸಾಧ್ಯವಾಗದೇ ಇರಬಹುದು. ಯಾವುದೇ ರಹಸ್ಯವನ್ನು ಸಂಪಾದಿಸುವ ಮೊದಲು ಆ ಪದರಗಳನ್ನು ಬೇರ್ಪಡಿಸಿ.
ಎನ್ಕೋಡಿಂಗ್, ಅಲ್ಗಾರಿದಮ್ ಮತ್ತು ಪ್ಯಾಕೇಜಿಂಗ್ ಮೂರು ಪದರಗಳು
ಕೀ ಫೈಲ್ಗೆ ಎನ್ಕೋಡಿಂಗ್, ಅಲ್ಗಾರಿದಮ್ ಮತ್ತು ಹೆಚ್ಚಾಗಿ ಕಂಟೇನರ್ ಇರುತ್ತದೆ. PEM ಪರಿಚಿತ base64 ಹೊದಿಕೆ; DER ಅದರ ಬೈನರಿ ಸಮಾನ; PKCS12 ಪ್ರಮಾಣಪತ್ರವನ್ನು ಅದರ ಕೀ ಮತ್ತು ಸರಪಳಿಯೊಂದಿಗೆ ಸೇರಿಸುತ್ತದೆ. ಪ್ರಮಾಣಪತ್ರ-ಸರಪಳಿ ಫೈಲ್ ಇನ್ನೊಂದು ಕಂಟೇನರ್, ಮತ್ತು ಅದರಲ್ಲಿ ಸಾಮಾನ್ಯವಾಗಿ ಯಾವುದೇ ಖಾಸಗಿ ಕೀ ಇರುವುದಿಲ್ಲ. ಈ ಯಾವ ಲೇಬಲ್ಗಳೂ ಒಳಗಿನ ವಸ್ತು RSA ಅಥವಾ ECDSA ಎಂದು ಹೇಳುವುದಿಲ್ಲ.
ಅಲ್ಗಾರಿದಮ್ ಅನ್ನು ವಸ್ತುವಿನಿಂದಲೇ ಓದಿ. ಪೂರೈಕೆದಾರರ ಮಾರ್ಕೆಟಿಂಗ್ ಹೆಸರು ಅಥವಾ ಫೈಲ್ ವಿಸ್ತರಣೆ ಸಾಕ್ಷಿಯಲ್ಲ, ಏಕೆಂದರೆ ಅದೇ ನೀಡುವವರು ಬೇರೆ ಬೇರೆ ಕೀ ಪ್ರಕಾರಗಳನ್ನು ನೀಡಬಹುದು.
ಲೋಡರ್ ಅನ್ನು ದೂಷಿಸುವ ಮೊದಲು ಸಾರ್ವಜನಿಕ ಕೀಗಳನ್ನು ಹೋಲಿಸಿ
ಲೋಡ್ ಆಗುವ ಪ್ರಮಾಣಪತ್ರವು ಪ್ರಮಾಣಪತ್ರವನ್ನು ಪಾರ್ಸ್ ಮಾಡಲಾಗಿದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ, ಅದರ ಖಾಸಗಿ ಕೀ ಇದೆ ಅಥವಾ ಬಳಸಬಹುದು ಎಂದಲ್ಲ. ಪ್ರಮಾಣಪತ್ರ ಮತ್ತು ಸೂಚಿಸಿದ ಖಾಸಗಿ ಕೀಯಿಂದ ಸಾರ್ವಜನಿಕ ಕೀಯನ್ನು ಪಡೆದು, ನಂತರ ಎರಡು ಡೈಜೆಸ್ಟ್ಗಳನ್ನು ಹೋಲಿಸಿ. ಯಾವುದೇ ಹೊರತೆಗೆಯುವಿಕೆ ವಿಫಲವಾದರೆ ಅಲ್ಲೇ ನಿಲ್ಲಿಸಿ, ಏಕೆಂದರೆ ಖಾಲಿ ಔಟ್ಪುಟ್ನ ಡೈಜೆಸ್ಟ್ ಏನನ್ನೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ. ಹೊಂದಿಕೆಯಾಗುವ ಡೈಜೆಸ್ಟ್ಗಳು ಜೋಡಿ ಒಟ್ಟಿಗೆ ಇದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸುತ್ತವೆ, ಮತ್ತು ಪ್ರಮಾಣಪತ್ರವು ಕೆಲಸಕ್ಕೆ ಸೂಕ್ತವೇ ಎಂಬ ಬಗ್ಗೆ ಹೆಚ್ಚೇನೂ ಅಲ್ಲ.
openssl x509 -in server.crt -pubkey -noout |
openssl pkey -pubin -outform DER |
openssl dgst -sha256
openssl pkey -in server-key.pem -pubout -outform DER |
openssl dgst -sha256
ಎರಡನೇ ಆಜ್ಞೆ ನಿಮ್ಮ ಯಂತ್ರದಲ್ಲಿನ ಖಾಸಗಿ ವಸ್ತುವನ್ನು ಸ್ಪರ್ಶಿಸುತ್ತದೆ ಆದರೆ ಸಾರ್ವಜನಿಕ ಅರ್ಧವನ್ನು ಮಾತ್ರ ಹೊರಡಿಸುತ್ತದೆ. ಹಾಗೆಯೇ ಇರಿಸಿ, ಮತ್ತು ಟಿಕೆಟ್ನಲ್ಲಿ ಎಂದಿಗೂ ಖಾಸಗಿ ಕೀ ಅಂಟಿಸಬೇಡಿ. ಕೀ ಎನ್ಕ್ರಿಪ್ಟ್ ಆಗಿದ್ದರೆ, ಬೆಂಬಲಿತ ಸಾಧನವು ಪಾಸ್ಫ್ರೇಸ್ ಕೇಳಲು ಬಿಡಿ, ಪ್ರಕ್ರಿಯೆ ಪಟ್ಟಿ ಬಹಿರಂಗಪಡಿಸಬಹುದಾದ ಆಜ್ಞಾ ಸಾಲಿನಲ್ಲಿ ಇಡುವ ಬದಲು.
ಹಳೆಯ ipsec.secrets ಅಥವಾ swanctl ರುಜುವಾತುಗಳು
strongSwan ನಲ್ಲಿ ಸಾಮಾನ್ಯವಾಗಿ ಬಳಸುವ ಎರಡು ರುಜುವಾತು ಮಾರ್ಗಗಳಿವೆ. ಹಳೆಯ starter ಸ್ಟಾಕ್ ಪ್ರಕಾರ-ನಿರ್ದಿಷ್ಟ ನಮೂದುಗಳನ್ನು ಇದರಿಂದ ಓದುತ್ತದೆ: ipsec.secrets, ಮತ್ತು ಪ್ರತಿ ನಮೂದು ವಸ್ತುವಿಗೆ ಸರಿಯಾದ ಪ್ರಕಾರವನ್ನು ಹೇಳಬೇಕು. swanctl ಮತ್ತು vici ಸ್ಟಾಕ್ ತನ್ನದೇ ರುಜುವಾತು ಕಡತಕೋಶದಿಂದ ತನ್ನದೇ ಸಂರಚನೆಯ ಮೂಲಕ ಕೀಗಳನ್ನು ಲೋಡ್ ಮಾಡುತ್ತದೆ. ಚಾಲನೆಯಲ್ಲಿರುವ backend ಓದದ ಫೈಲ್ ಅನ್ನು ಸಂಪಾದಿಸುವುದರಿಂದ ಏನೂ ಬದಲಾಗುವುದಿಲ್ಲ.
: ECDSA "/etc/ipsec.d/private/server-key.pem"
ಯಾವ backend ನಿಜವಾಗಿ ಚಾಲನೆಯಲ್ಲಿದೆ ಎಂದು ಕಂಡುಹಿಡಿಯಿರಿ, ನಂತರ ಕೀಯನ್ನು ಆ backend ನೋಡುವ ಸ್ಥಳದಲ್ಲಿ ಇರಿಸಿ. strongSwan 5.9 ಹಳೆಯ ಕೈಪಿಡಿ ಪ್ರಕಾರ-ನಿರ್ದಿಷ್ಟ ರಹಸ್ಯ ನಮೂದುಗಳನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತದೆ, ಮತ್ತು ಇದು swanctl ದಾಖಲೆ ಅಲ್ಲ. ಎರಡನ್ನೂ ಬೆರೆಸಿದರೆ ನಿರ್ವಾಹಕರು ಪ್ರಾಮಾಣಿಕ ಎಂದು ಭಾವಿಸುವ ಫೈಲ್ ಅನ್ನು ನಿರ್ಲಕ್ಷಿಸುವ daemon ಉಂಟಾಗುತ್ತದೆ. ದೋಷ ವರದಿ ಮಾಡದ ಮರುಲೋಡ್ ಎಂದರೆ ಸಂರಚನೆ ಪಾರ್ಸ್ ಆಗಿದೆ ಎಂದಷ್ಟೇ.
ಲೋಡ್ ಘಟನೆ ಮತ್ತು ದೃಢೀಕರಣ ಫಲಿತಾಂಶವನ್ನು ಓದಿ
ನಿಯಂತ್ರಿತ ಮರುಲೋಡ್ ನಂತರ, ನಿರ್ದಿಷ್ಟ ಕೀಗಾಗಿ daemon ನ ಸ್ವಂತ ಲೋಡಿಂಗ್ ಔಟ್ಪುಟ್ ಓದಿ. ಸ್ಥಿತಿ ಡಂಪ್ನಲ್ಲಿ ಪಟ್ಟಿ ಮಾಡಿದ ಪ್ರಮಾಣಪತ್ರವು ಖಾಸಗಿ ಕೀ ಅದರೊಂದಿಗೆ ಹೊಂದಿಸಲಾಗಿದೆ ಎಂದು ತೋರಿಸುವುದಿಲ್ಲ.
ಕ್ಲೈಂಟ್ ಇನ್ನೂ ವಿಫಲವಾದರೆ, ಸರ್ವರ್ ಘಟನೆ ಮತ್ತು ಕ್ಲೈಂಟ್ ದೋಷವನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಇರಿಸಿ. ಸರಪಳಿ ಮೌಲ್ಯೀಕರಣ, ಗುರುತಿನ ಹೊಂದಾಣಿಕೆ ಮತ್ತು ವಿಧಾನ ಹೊಂದಾಣಿಕೆ ತಮ್ಮದೇ ಸಾಕ್ಷ್ಯಗಳನ್ನು ಹೊಂದಿರುವ ನಂತರದ ಪ್ರಶ್ನೆಗಳು. ಫಲಿತಾಂಶವನ್ನು ನಿಖರ ಕೀ ಮಾರ್ಗ ಮತ್ತು ನೀವು ಹೋಲಿಸಿದ ಡೈಜೆಸ್ಟ್ನೊಂದಿಗೆ ಬರೆಯಿರಿ, ಇಲ್ಲದಿದ್ದರೆ ಮುಂದಿನ ಪಾಳಿ ಅದೇ ಮರುಲೋಡ್ ಅನ್ನು ಪುನರಾವರ್ತಿಸುತ್ತದೆ. ಲೋಡರ್ ಹೊಂದಾಣಿಕೆಯಿಲ್ಲದಿರುವಿಕೆಗೆ CA ಬದಲಾಯಿಸುವುದು ಮೊದಲ ಪ್ರತಿಕ್ರಿಯೆ ಅಲ್ಲ.