SoftEther ServerCertSet: vpncmd ನೊಂದಿಗೆ ನವೀಕರಿಸಿದ ಸರಪಳಿಯನ್ನು ಆಮದು ಮಾಡಿ

Certbot ಯಶಸ್ವಿ ನವೀಕರಣವನ್ನು ವರದಿ ಮಾಡುತ್ತದೆ, ಡಿಸ್ಕ್‌ನಲ್ಲಿರುವ ಫೈಲ್‌ಗಳು ಹೊಸ ದಿನಾಂಕಗಳನ್ನು ಹೊಂದಿವೆ, ಆದರೆ ಗ್ರಾಹಕರು ಇನ್ನೂ ಹಳೆಯ ಗುರುತನ್ನು ಎದುರಿಸುತ್ತಾರೆ. SoftEther ತನ್ನ SSL ಸರ್ವರ್ ಪ್ರಮಾಣಪತ್ರವನ್ನು ತನ್ನದೇ ಸರ್ವರ್-ಮಟ್ಟದ ಸಂರಚನೆಯಲ್ಲಿ ಇರಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಡಿಸ್ಕ್‌ನಲ್ಲಿನ ಹೊಸ ಫೈಲ್ ಎಲೆ ಮತ್ತು ಅದರ ಕೀಲಿಯನ್ನು ಆಮದು ಮಾಡುವವರೆಗೆ ಏನನ್ನೂ ಬದಲಿಸುವುದಿಲ್ಲ. ಕೆಳಗಿನ ಅನುಕ್ರಮವು ಒಂದು ಕೈಯಿಂದ ಮಾಡಿದ ಆಮದು, ಪ್ರತಿ ನವೀಕರಣದ ನಂತರ ಚಲಿಸುವ ಸುತ್ತುವರಿಕೆ, ಮತ್ತು ಆಲಿಸುವವನು ನಿಜವಾಗಿ ಏನನ್ನು ಪ್ರಸ್ತುತಪಡಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಓದುವ ಪರಿಶೀಲನೆಯನ್ನು ಒಳಗೊಂಡಿದೆ. ಪ್ರತಿ ಹಂತವೂ ಮುಂದಿನ ನವೀಕರಣದ ನಂತರ ಹೋಲಿಸಬಹುದಾದ ಸಾಕ್ಷ್ಯವನ್ನು ಬಿಡುತ್ತದೆ.

ನವೀಕರಿಸಿದ ಫೈಲ್ ಸರ್ವರ್‌ನ ಗುರುತನ್ನು ಬದಲಿಸುವುದಿಲ್ಲ

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

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

ಆಲಿಸುವವನಿಗೆ ಹೊಂದುವ ಸವಾಲನ್ನು ಆಯ್ಕೆಮಾಡಿ

ಪ್ರಮಾಣಪತ್ರವು ಗ್ರಾಹಕರು ಪರಿಶೀಲಿಸುವ ಹೋಸ್ಟ್ ಅನ್ನು ಹೆಸರಿಸಬೇಕು, ಆದ್ದರಿಂದ ಒಳಗಿನ ಲೇಬಲ್ ಅಥವಾ ವಿಳಾಸದ ಬದಲು ಸಾರ್ವಜನಿಕ DNS ಹೆಸರನ್ನು ಬಳಸಿ. HTTP-01 ಗೆ ಸವಾಲಿಗೆ ಕ್ಷಣಕಾಲ ಪೋರ್ಟ್ 80 ನಲ್ಲಿ ಉತ್ತರಿಸಬೇಕು, ಅದು ತಾತ್ಕಾಲಿಕ ಆಲಿಸುವವನು ಮತ್ತು SoftEther ನ ಸ್ವಂತ ಪೋರ್ಟ್ ಅನ್ನು ಸರಿಸಲು ಎಂದಿಗೂ ಕಾರಣವಲ್ಲ. DNS-01 ದಾಖಲೆಯ ಮೂಲಕ ನಿಯಂತ್ರಣವನ್ನು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ ಮತ್ತು ಒಳಬರುವ HTTP ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಅಗತ್ಯವಿಲ್ಲ.

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

ಇಲ್ಲಿರುವವರೆಗೆ ಕಲಾಕೃತಿಗಳನ್ನು ಅಚ್ಚುಕಟ್ಟಾಗಿ ಇರಿಸಿ. ಎಲೆ ಮತ್ತು ಮಧ್ಯಂತರ ಪ್ರಮಾಣಪತ್ರಗಳು ಪ್ರತ್ಯೇಕ ಫೈಲ್‌ಗಳಾಗಿ ಮತ್ತು ಒಂದು ಸಂಯೋಜಿತ ಸರಪಳಿ ಫೈಲ್ ಆಗಿ ಬರುತ್ತವೆ, ಖಾಸಗಿ ಕೀಲಿ ಮತ್ತೆ ಪ್ರತ್ಯೇಕ, ಮತ್ತು ಆಮದಿಗೆ ಅದರ ಹೊಂದುವ ಕೀಲಿಯೊಂದಿಗೆ ಸರಪಳಿ ಬೇಕು, ಒಂಟಿ ಸಾರ್ವಜನಿಕ ಪ್ರಮಾಣಪತ್ರವಲ್ಲ.

ಸರಪಳಿಯನ್ನು ಸರ್ವರ್ ಮಟ್ಟದಲ್ಲಿ ಆಮದು ಮಾಡಿ

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

ServerCertSet /LOADCERT:/etc/letsencrypt/live/vpn.example.com/fullchain.pem /LOADKEY:/etc/letsencrypt/live/vpn.example.com/privkey.pem

ಯಶಸ್ಸನ್ನು ಊಹಿಸುವ ಬದಲು ಆದೇಶದ ಔಟ್‌ಪುಟ್ ಓದಿ, ನಂತರ ನೀವು ನೀಡಿದ ಫೈಲ್ ಅನ್ನು ನಂಬುವ ಬದಲು ಸರಪಳಿಯನ್ನು ಮತ್ತೆ ಓದಿ. ಇಡೀ PEM ಬಂಡಲ್ ಆಮದು ಮಾಡುವ ಬಿಲ್ಡ್‌ಗಳು ಮತ್ತು ಮೊದಲ ಪ್ರಮಾಣಪತ್ರವನ್ನು ಮಾತ್ರ ತೆಗೆದುಕೊಳ್ಳುವ ಬಿಲ್ಡ್‌ಗಳ ನಡುವಿನ ಗಡಿ ಒಂದೇ ಸ್ಥಳದಲ್ಲಿ ದಾಖಲಾಗಿಲ್ಲ, ಆದ್ದರಿಂದ ನಿಮ್ಮ ಮುಂದಿರುವ ಬಿಲ್ಡ್‌ಗೆ ಪರಿಶೀಲನೆಯೇ ನಿರ್ಣಯಿಸುತ್ತದೆ. ಆಲಿಸುವವನು ಪ್ರಸ್ತುತಪಡಿಸುವ ಪ್ರಮಾಣಪತ್ರಗಳನ್ನು ಎಣಿಸಿ; ಮಧ್ಯಂತರವಿಲ್ಲದ ಎಲೆ ಮೊದಲ ಬ್ಲಾಕ್ ಅನ್ನು ಮಾತ್ರ ಬಳಸಿದ ಆಮದುದಾರನ ಸಹಿ.

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

ನಿಯೋಜನೆಯನ್ನು ಹುಕ್ ಮಾಡಿ, ನವೀಕರಣವನ್ನಲ್ಲ

ಕೈಯಿಂದ ಮಾಡಿದ ಆಮದು ಕೆಲಸ ಮಾಡಿದ ನಂತರ, ಆ ಹಂತಗಳನ್ನೇ ಒಂದು ಸಣ್ಣ ಸುತ್ತುವರಿಕೆಯಲ್ಲಿ ಇರಿಸಿ ಮತ್ತು ಯಶಸ್ವಿ ನವೀಕರಣದ ನಂತರ ACME ಗ್ರಾಹಕದಿಂದ ಅದನ್ನು ಕರೆಯಿರಿ. Certbot ಹುಕ್‌ಗಾಗಿ RENEWED_LINEAGE ಮತ್ತು RENEWED_DOMAINS ಅನ್ನು ಸೆಟ್ ಮಾಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಹಲವನ್ನು ನಿರ್ವಹಿಸುವ ಯಂತ್ರದಲ್ಲಿ ಸುತ್ತುವರಿಕೆ ಒಂದು ಪ್ರಮಾಣಪತ್ರದ ಮೇಲೆ ಕಾರ್ಯನಿರ್ವಹಿಸಬಹುದು. ಹೋಸ್ಟ್‌ನ ಪ್ರತಿ ನವೀಕರಣಕ್ಕೆ ಪ್ರತಿಕ್ರಿಯಿಸುವ ಬದಲು ವಂಶಾವಳಿಯ ಮೇಲೆ ಫಿಲ್ಟರ್ ಮಾಡಿ. ಸುತ್ತುವರಿಕೆ ಸರ್ವರ್‌ನ ಸವಲತ್ತುಗಳೊಂದಿಗೆ ಚಲಿಸುವ ನಿಯೋಜನೆ ಕೋಡ್, ಆದ್ದರಿಂದ ಆ ಸ್ಥಾನದಲ್ಲಿನ ಯಾವುದೇ ಸ್ಕ್ರಿಪ್ಟ್‌ನಂತೆ ಅದನ್ನು ಪರಿಶೀಲಿಸಿ.

certbot renew --deploy-hook /usr/local/sbin/softether-deploy.sh

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

ಪ್ರಸ್ತುತಪಡಿಸಿದ ಸರಪಳಿಯನ್ನು ಫೈಲಿನೊಂದಿಗೆ ಹೋಲಿಸಿ

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

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts </dev/null 2>/dev/null | grep -c 'BEGIN CERTIFICATE'
openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -dates -fingerprint -sha256

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