VPN ಕ್ಲೈಂಟ್ ಕೀಲಿಯನ್ನು ರಚಿಸುವುದು ಮತ್ತು ಸಹಿಗಾಗಿ CSR ಸಲ್ಲಿಸುವುದು ಹೇಗೆ

ಬೇಗನೆ ಅಥವಾ ತಡವಾಗಿ, VPN ಬಳಕೆದಾರರು ಖಾಸಗಿ ಕೀಲಿಯನ್ನು ಇಮೇಲ್ ಮೂಲಕ ಕಳುಹಿಸಲು ಮುಂದಾಗುತ್ತಾರೆ, ಇದರಿಂದ ನಿರ್ವಾಹಕರು ಪ್ರಮಾಣಪತ್ರವನ್ನು ರಚಿಸಬಹುದು, ಮತ್ತು ನಿರಾಕರಿಸಬೇಕಾದದ್ದು ನಿಖರವಾಗಿ ಆ ಪ್ರಸ್ತಾಪವೇ. ಕೆಲಸ ಮಾಡುವ ಹರಿವು ಮೊದಲ ಆದೇಶದಿಂದಲೇ ಕೀಲಿಯನ್ನು ಕ್ಲೈಂಟ್‌ನಲ್ಲಿ ಇರಿಸುತ್ತದೆ: ಕ್ಲೈಂಟ್ ಅದನ್ನು ರಚಿಸುತ್ತದೆ, ಪ್ರಮಾಣಪತ್ರ ಸಹಿ ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸುತ್ತದೆ, ನೀಡುವವರು ಅದನ್ನು ಪರಿಶೀಲಿಸಿ ಅಧಿಕಾರ ನೀಡುತ್ತಾರೆ, ಮತ್ತು ಸಹಿ ಮಾಡಿದ ಪ್ರಮಾಣಪತ್ರವು ಅದನ್ನು ರಚಿಸಿದ ಕೀಲಿಯ ಪಕ್ಕದಲ್ಲಿ ಕುಳಿತುಕೊಳ್ಳಲು ಹಿಂತಿರುಗುತ್ತದೆ. ಕೆಳಗಿನ ಪರಿಶೀಲನಾ ಪಟ್ಟಿ ಪ್ರತಿ ಹಂತದಲ್ಲೂ ಮುಚ್ಚಿದ ರೀತಿಯಲ್ಲಿ ವಿಫಲವಾಗುತ್ತದೆ, ಮತ್ತು ಅದೇ ಮುಖ್ಯ ಅಂಶ, ಏಕೆಂದರೆ ಐದು ಹಂತಗಳಲ್ಲಿ ಎರಡು ಜನರು ಆತುರದಲ್ಲಿದ್ದಾಗ ಬಿಟ್ಟುಬಿಡುವ ಹಂತಗಳು.

ಹಂತ 1: ಕೀಲಿ ಇರುವ ಸ್ಥಳದಲ್ಲೇ ಅದನ್ನು ರಚಿಸಿ

ಕೀಲಿಯನ್ನು ಇಟ್ಟುಕೊಳ್ಳುವ ಯಂತ್ರದಲ್ಲೇ ರಚಿಸಿ ಮತ್ತು ಅಲ್ಲೇ ಬಿಡಿ. ಸಾಫ್ಟ್‌ವೇರ್ ಕೀಲಿ ಕಟ್ಟುನಿಟ್ಟಾದ ಅನುಮತಿಗಳಿರುವ ಕಡತಕ್ಕೆ ಹೋಗುತ್ತದೆ; ಯಂತ್ರಾಂಶ-ಬೆಂಬಲಿತ ಅಥವಾ ನಿರ್ವಹಿತ ಸಂಗ್ರಹದಲ್ಲಿರುವ ಕೀಲಿ ಎಂದಿಗೂ ಕಡತವಾಗುವುದಿಲ್ಲ, ಮತ್ತು ಅದರ ನೋಂದಣಿ ಮಾರ್ಗ ಸಾಮಾನ್ಯವಾಗಿ OpenSSL ಆದೇಶವಲ್ಲ, ಬೇರೆ ಉಪಕರಣ. ಹೇಗಾದರೂ, ಖಾಸಗಿ ಅರ್ಧವನ್ನು ಯಾರೂ ನೋಡಬೇಕಾಗಿಲ್ಲ.

ಸಾಫ್ಟ್‌ವೇರ್ ಹರಿವು ಹೀಗಿರುತ್ತದೆ, ಕೀಲಿ ಮತ್ತು ವಿನಂತಿ ಒಂದೇ ಅವಧಿಯಲ್ಲಿ ರಚಿಸಲ್ಪಡುತ್ತವೆ:

umask 077
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:3072 -out client.key
openssl req -new -key client.key -out client.csr -subj "/CN=alice-vpn/O=Example"

umask ಸಾಲು ಕಾಣುವುದಕ್ಕಿಂತ ಹೆಚ್ಚು ಮುಖ್ಯ. ಅದಿಲ್ಲದೆ, ಡೀಫಾಲ್ಟ್ ಆಗಿ ಅನುಮತಿಸುವ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಕೀಲಿಯನ್ನು ಎಲ್ಲರೂ ಓದುವಂತೆ ಬರೆಯಲಾಗುತ್ತದೆ, ಮತ್ತು ನಂತರ ಕಡತವನ್ನು ನಕಲಿಸುವುದು ಅದನ್ನು ಹರಡುತ್ತದೆ. ಇರುವ ಕೀಲಿಯನ್ನು ಮರುಬಳಕೆ ಮಾಡುವುದು ಅದು ಈಗಾಗಲೇ ಸಂರಕ್ಷಿತವಾಗಿದ್ದು ನಿಮ್ಮ ನೀತಿಗೆ ಹೊಂದಿದ್ದರೆ ಕಾನೂನುಬದ್ಧ; ಪ್ರತಿ ಸಾಧನಕ್ಕೂ ಹೊಸದನ್ನು ರಚಿಸುವುದು ವಿವರಿಸಲು ಸುಲಭ.

ಹಂತ 2: ಗುರುತನ್ನು ವಿನಂತಿಯಲ್ಲಿ ಇರಿಸಿ, ಇಮೇಲ್‌ನಲ್ಲಿ ಅಲ್ಲ

ವಿನಂತಿ ರಚನೆಯಾಗುವ ಮೊದಲು VPN ನಿಜವಾಗಿ ಯಾವುದನ್ನು ದೃಢೀಕರಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಿ, ಏಕೆಂದರೆ ಆ ಉತ್ತರ CSR ಒಳಗೆ ಸೇರುತ್ತದೆ. OpenVPN ಸಾಂಪ್ರದಾಯಿಕವಾಗಿ ಕ್ಲೈಂಟ್ ಗುರುತನ್ನು ಪ್ರಮಾಣಪತ್ರದ ಸಾಮಾನ್ಯ ಹೆಸರಿಗೆ ಬಂಧಿಸುತ್ತದೆ, ಮತ್ತು strongSwan ನಂತಹ ಉಪಕರಣಗಳು ಗುರುತಿನ ಸರಣಿಯನ್ನು ವಿಷಯ ಅಥವಾ ವಿಷಯದ ಪರ್ಯಾಯ ಹೆಸರಿಗೆ ಹೊಂದಿಸುತ್ತವೆ. ನನ್ನ ಹೆಸರು alice ಎಂದು ಹೇಳುವ ಇಮೇಲ್ ಸಾಕ್ಷ್ಯವಲ್ಲ, ಮತ್ತು ವಿಷಯವು ಅದನ್ನೇ ಹೇಳುವ ವಿನಂತಿ ಸ್ವಲ್ಪ ಮಾತ್ರ ಉತ್ತಮ.

ನಿಮ್ಮ ಪರಿಶೀಲಕವು ಒಂದನ್ನು ಪರಿಶೀಲಿಸಿದಾಗ ವಿಷಯದ ಪರ್ಯಾಯ ಹೆಸರನ್ನು ಸೇರಿಸಿ, ಏಕೆಂದರೆ ಆಧುನಿಕ ಹೊಂದಾಣಿಕೆ ಹಳೆಯ CN ಅನ್ನು ಹೆಚ್ಚಾಗಿ ನಿರ್ಲಕ್ಷಿಸುತ್ತದೆ:

openssl req -new -key client.key -out client.csr \
  -subj "/CN=alice-vpn/O=Example" \
  -addext "subjectAltName=DNS:alice-vpn"

CN ಅನ್ನು ಚಿಕ್ಕದಾಗಿ, ಸ್ಥಿರವಾಗಿ ಮತ್ತು ಲ್ಯಾಪ್‌ಟಾಪ್ ಮಾದರಿಗೆ ಬದಲಾಗಿ ಖಾತೆಗೆ ಬಂಧಿಸಿ ಇರಿಸಿ. ಬಳಕೆದಾರರ ಸಾಧನದ ಸರಣಿ ಸಂಖ್ಯೆಯನ್ನು ಹೊಂದಿರುವ ಹೆಸರು ಮೊದಲ ಯಂತ್ರಾಂಶ ಬದಲಾವಣೆಗೆ ಕಾಯುತ್ತಿರುವ ಬೆಂಬಲ ಸಮಸ್ಯೆ.

ಹಂತ 3: ಸಹಿ ಮಾಡುವ ಮೊದಲು ವಿನಂತಿಯನ್ನು ಪರಿಶೀಲಿಸಿ

ನೀಡುವವರು ಎರಡು ವಿಭಿನ್ನ ವಿಷಯಗಳನ್ನು ಪರಿಶೀಲಿಸುತ್ತಾರೆ, ಮತ್ತು ಅವನ್ನು ಬೆರೆಸುವುದು ಶಾಸ್ತ್ರೀಯ ತಪ್ಪು. ಮೊದಲನೆಯದು, ವಿನಂತಿ ಆಂತರಿಕವಾಗಿ ಸುಸಂಗತವಾಗಿದೆ: ಸಹಿಯನ್ನು ಅದು ಹೊತ್ತಿರುವ ಸಾರ್ವಜನಿಕ ಕೀಲಿಯ ವಿರುದ್ಧ ಪರಿಶೀಲಿಸಲಾಗುತ್ತದೆ. ಎರಡನೆಯದು, ವಿನಂತಿದಾರರು ವಿನಂತಿ ಕೇಳುವುದಕ್ಕೆ ಅರ್ಹರಾಗಿದ್ದಾರೆ, ಮತ್ತು ಅದಕ್ಕೆ ಯಾವುದೇ ಗೂಢಲಿಪಿ ಪರಿಶೀಲನೆ ಉತ್ತರಿಸಲಾರದು.

ಯಾಂತ್ರಿಕ ಭಾಗವು ಒಂದು ಆದೇಶ, ಮತ್ತು ಅದು ವಿಷಯದೊಂದಿಗೆ ಪರಿಶೀಲನಾ ಫಲಿತಾಂಶವನ್ನು ಮುದ್ರಿಸಬೇಕು:

openssl req -in client.csr -noout -verify -subject
openssl req -in client.csr -noout -pubkey | openssl pkey -pubin -noout -text

ಅದು ಏನನ್ನು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಗಮನಿಸಿ. ಪರಿಶೀಲನೆಗೆ ಒಳಪಡುವ ವಿನಂತಿ ಕೇವಲ ಸಲ್ಲಿಸುವ ಸಮಯದಲ್ಲಿ ಕಳುಹಿಸುವವರ ಬಳಿ ಹೊಂದಿಕೆಯಾಗುವ ಖಾಸಗಿ ಕೀಲಿ ಇತ್ತು ಎಂಬುದನ್ನು ತೋರಿಸುತ್ತದೆ; ಕಳುಹಿಸುವವರು ವಿಷಯದಲ್ಲಿ ಹೆಸರಿಸಲಾದ ವ್ಯಕ್ತಿ ಎಂದು ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಕೇಳಲಾದ ಗುಂಪು ಅಥವಾ ಮಾರ್ಗ ಪ್ರವೇಶವನ್ನು ಅಧಿಕಾರ ನೀಡುವುದಿಲ್ಲ. ನೋಂದಣಿ ಪರಿಶೀಲನೆ ಪ್ರತ್ಯೇಕ ದ್ವಾರ, ಮತ್ತು ಯಾರೂ ಅನುಮೋದಿಸದ ಗುಂಪನ್ನು ಕೇಳುವ ವಿನಂತಿಯನ್ನು ಸದ್ದಿಲ್ಲದೆ ಸಂಪಾದಿಸುವ ಬದಲು ತಿರಸ್ಕರಿಸಬೇಕು.

ಹಂತ 4: ಅಧಿಕಾರ ನೀಡಿ, ನಂತರ ಸ್ಪಷ್ಟ ವಿಸ್ತರಣೆಗಳೊಂದಿಗೆ ಸಹಿ ಮಾಡಿ

ವಿನಂತಿಯನ್ನು ಅಕ್ಷರಶಃ ಸ್ವೀಕರಿಸುವ ಬದಲು CA ನೀತಿಯನ್ನು ನಿರ್ಧರಿಸುವ ಸ್ಥಳವೇ ಸಹಿ. ಮಾನ್ಯತೆ, ಕೀಲಿ ಬಳಕೆ ಮತ್ತು ಪಾತ್ರ ವಿಸ್ತರಣೆ ವಿಸ್ತರಣಾ ಕಡತದಲ್ಲಿರಬೇಕು, ಆರು ತಿಂಗಳ ನಂತರ ನಿಮಗೆ ನೆನಪಿರದ ಡೀಫಾಲ್ಟ್‌ಗಳಲ್ಲ. VPN ದೃಢೀಕರಣಕ್ಕಾಗಿ ಕ್ಲೈಂಟ್ ಪ್ರಮಾಣಪತ್ರಕ್ಕೆ ಅದರ ಉದ್ದೇಶವಾಗಿ ಕ್ಲೈಂಟ್ ದೃಢೀಕರಣ ಬೇಕು.

cat > client.ext <<'EOF'
basicConstraints = CA:FALSE
keyUsage = digitalSignature
extendedKeyUsage = clientAuth
EOF
openssl x509 -req -in client.csr -CA ca.crt -CAkey ca.key \
  -CAcreateserial -days 365 -extfile client.ext -out client.crt

ಈಗಾಗಲೇ ಒಂದು ಬಳಕೆಯಲ್ಲಿದ್ದರೆ ಇರುವ ಸರಣಿ ಕಡತದೊಂದಿಗೆ -CAserial ಬಳಸಿ, ಮತ್ತು CA ಕೀಲಿಯನ್ನು ಆಫ್‌ಲೈನ್ ಅಥವಾ ನಿಮ್ಮ ನೀತಿ ಹೆಸರಿಸುವ ಸಂರಕ್ಷಿತ ಸಂಗ್ರಹದಲ್ಲಿ ಇರಿಸಿ. ಪ್ರಮಾಣಪತ್ರಗಳ ಸರಣಿ ಸಂಖ್ಯೆಗಳು ಪ್ರತಿ ನೀಡುವವರಿಗೂ ಅನನ್ಯವಾಗಿರಬೇಕು; ಸರಣಿ ಕಡತವನ್ನು ಶೂನ್ಯದಿಂದ ಮರುರಚಿಸುವುದು ರದ್ದತಿಯನ್ನು ಅಸ್ಪಷ್ಟಗೊಳಿಸುವ ಘರ್ಷಣೆಗಳ ಅಪಾಯವನ್ನು ತರುತ್ತದೆ.

ಏನು ನೀಡಲಾಗಿದೆ ಎಂಬುದನ್ನು ದಾಖಲಿಸಿ: ಸರಣಿ, ವಿಷಯ, ಕೇಳಿದ ಗುರುತು, ಅನುಮೋದಿಸಿದ ವ್ಯಕ್ತಿ ಮತ್ತು ಮುಕ್ತಾಯ. ಆ ದಾಖಲೆಯೇ ನಂತರ ರದ್ದತಿ ನಿರ್ಧಾರ ಅವಲಂಬಿಸುವುದು, ಮತ್ತು ನೋಂದಣಿಯ ಕುರುಹು ಕೇವಲ ಅಂಚೆಪೆಟ್ಟಿಗೆಯಲ್ಲಿ ಮಾತ್ರ ಇದ್ದರೆ ಅದನ್ನು ಪ್ರಮಾಣಪತ್ರದಿಂದಲೇ ಮರುನಿರ್ಮಿಸಲಾಗದು.

ಹಂತ 5: ಅದನ್ನು ಹೊಂದಿಕೆಯಾಗುವ ಕೀಲಿಯ ಪಕ್ಕದಲ್ಲಿ ಸ್ಥಾಪಿಸಿ ಮತ್ತು ಜೋಡಿಯನ್ನು ಸಾಬೀತುಪಡಿಸಿ

ಕ್ಲೈಂಟ್ ಪ್ರಮಾಣಪತ್ರ ಮತ್ತು ನೀಡುವವರ ಸರಪಳಿಯನ್ನು ಪಡೆಯುತ್ತದೆ, ಎಂದಿಗೂ ಕೀಲಿಯನ್ನಲ್ಲ. ಸಂಪರ್ಕಿಸುವ ಮೊದಲು, ಪ್ರಮಾಣಪತ್ರವು ಡಿಸ್ಕ್‌ನಲ್ಲಿರುವ ಕೀಲಿಯೊಂದಿಗೆ ನಿಜವಾಗಿಯೂ ಜೋಡಿಯಾಗುತ್ತದೆ ಎಂದು ದೃಢೀಕರಿಸಿ, ಏಕೆಂದರೆ ಹೊಂದಿಕೆಯಾಗದ ಜೋಡಿ ಬಹಳ ತಡವಾಗಿ ಗೊಂದಲಮಯ ಹಸ್ತಲಾಘವ ವಿಫಲತೆಯನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ:

openssl x509 -in client.crt -noout -pubkey | openssl pkey -pubin -outform DER | openssl sha256
openssl pkey -in client.key -pubout -outform DER | openssl sha256

ಎರಡೂ ಡೈಜೆಸ್ಟ್‌ಗಳು ಹೊಂದಿಕೆಯಾಗಬೇಕು. ನಂತರ ಸಂಪರ್ಕಿಸಿ ಮತ್ತು ಸರ್ವರ್ ದಾಖಲಿಸುವ ಗುರುತು ನೀವು ಅಧಿಕಾರ ನೀಡಿದ್ದೇ ಎಂದು ದೃಢೀಕರಿಸಿ, ಕೇವಲ ಸುರಂಗ ಏರಿತು ಎಂದಲ್ಲ. ಕೀಲಿ ಕಳೆದುಹೋದರೆ ಅಥವಾ ಸಾಧನ ಬದಲಾದರೆ, ಉತ್ತರ ರದ್ದತಿ ಜೊತೆಗೆ ಹೊಸ ಸಾಧನದಿಂದ ಹೊಸ ವಿನಂತಿ; ನಿರ್ವಾಹಕರನ್ನು ಬೇರೆಡೆಯಿಂದ ಕೀಲಿಯನ್ನು ಹಿಂತಿರುಗಿಸಲು ಕೇಳುವುದು ಮೂಲವನ್ನು ಮರುಪಡೆಯುವುದಿಲ್ಲ ಮತ್ತು ವಿನಂತಿಯನ್ನು ಸುರಕ್ಷಿತಗೊಳಿಸಿದ ಮಾದರಿಯನ್ನು ಸದ್ದಿಲ್ಲದೆ ಮುರಿಯುತ್ತದೆ.