ਨਿੱਜੀ CA ਬੈਕਅਪ: ਐਨਕ੍ਰਿਪਟਿਡ ਆਰਕਾਈਵ ਬਨਾਮ HSM ਕੁੰਜੀ ਬੈਕਅਪ
ਐਨਕ੍ਰਿਪਟਿਡ ਆਰਕਾਈਵ ਜਾਂ HSM-ਲਪੇਟੀ ਕੁੰਜੀ: ਹਰ VPN CA ਬੈਕਅਪ ਮਾਡਲ ਕਿਵੇਂ ਬਹਾਲ ਹੁੰਦਾ ਹੈ, ਇਸ ਵਿੱਚ ਕੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਕਿਹੜੀ ਨਾਕਾਮੀ ਤੋਂ ਤੁਸੀਂ ਸੱਚਮੁੱਚ ਬਚ ਸਕਦੇ ਹੋ।
ਇਸ ਵਿੱਚੋਂ ਬਹੁਤਾ ਹਿੱਸਾ ਤੈਅ ਕਰਨ ਵਾਲਾ ਸਵਾਲ ਇਹ ਨਹੀਂ ਕਿ ਤੁਸੀਂ ਆਰਕਾਈਵ ਨੂੰ ਕਿਵੇਂ ਐਨਕ੍ਰਿਪਟ ਕਰਦੇ ਹੋ। ਇਹ ਹੈ ਕਿ ਤੁਹਾਡੀ CA ਨਿੱਜੀ ਕੁੰਜੀ ਆਪਣੇ ਕੰਟੇਨਰ ਤੋਂ ਬਾਹਰ ਨਿਕਲ ਸਕਦੀ ਹੈ ਜਾਂ ਨਹੀਂ। ਜੇ ਕੁੰਜੀ ਫਾਈਲ ਹੈ, ਤੁਸੀਂ ਪੂਰੀ CA ਡਾਇਰੈਕਟਰੀ ਨੂੰ ਇੱਕ ਐਨਕ੍ਰਿਪਟਿਡ ਬਲਾਬ ਵਿੱਚ ਕਾਪੀ ਕਰਕੇ ਮਿੰਟਾਂ ਵਿੱਚ ਮੁਕਾ ਸਕਦੇ ਹੋ। ਜੇ ਇਹ ਕਿਸੇ HSM ਜਾਂ ਅਜਿਹੇ ਟੋਕਨ ਵਿੱਚ ਰਹਿੰਦੀ ਹੈ ਜੋ ਕੁੰਜੀ ਨੂੰ ਨਾ-ਕੱਢਣਯੋਗ ਦੱਸਦਾ ਹੈ, ਤਾਂ ਉਹ ਕਾਪੀ ਨਹੀਂ ਹੈ, ਅਤੇ ਤੁਹਾਡੀ ਯੋਜਨਾ ਵਿਕਰੇਤਾ ਦੀ ਲਪੇਟਣ-ਅਤੇ-ਬਹਾਲੀ ਕਾਰਵਾਈ ਬਾਰੇ ਯੋਜਨਾ ਬਣ ਜਾਂਦੀ ਹੈ। ਦੋਵੇਂ ਮਾਡਲ ਕੰਮ ਕਰਦੇ ਹਨ, ਵੱਖਰੇ ਢੰਗ ਨਾਲ ਫੇਲ੍ਹ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਜਿਸ ਨਾਕਾਮੀ ਤੋਂ ਤੁਸੀਂ ਬਚ ਸਕਦੇ ਹੋ ਉਹੀ ਡਿਜ਼ਾਈਨ ਕਰਨ ਯੋਗ ਹੈ।
ਦੋ ਬੈਕਅਪ ਮਾਡਲ ਕਿੱਥੇ ਵੱਖ ਹੁੰਦੇ ਹਨ
ਮਾਡਲ A ਡਾਇਰੈਕਟਰੀ ਕਾਪੀ ਹੈ। OpenSSL ਸ਼ੈਲੀ ਦੀ CA ਇੱਕ ਕੰਮ ਕਰਨ ਵਾਲੀ ਡਾਇਰੈਕਟਰੀ ਹੈ, ਇੱਕ ਸਰਟੀਫਿਕੇਟ ਨਹੀਂ: ca.key ਜਾਂ cakey.pem, ca.crt, ਇਸ਼ੂਅੰਸ ਡੇਟਾਬੇਸ, serial ਅਤੇ crlnumber ਕਾਊਂਟਰ, ਅਤੇ openssl.cnf। ਉਸ ਡਾਇਰੈਕਟਰੀ ਨੂੰ ਸਮਮਿਤੀ ਸਾਈਫਰ ਨਾਲ ਸੀਲ ਕਰੋ, ਨਤੀਜਾ ਦੂਜੇ ਮਾਧਿਅਮ ਵਿੱਚ ਲੈ ਜਾਓ, ਅਤੇ ਬਹਾਲੀ ਦਾ ਅਰਥ ਹੈ ਖੋਲ੍ਹਣਾ, ਪਰਖਣਾ, ਦਸਤਖ਼ਤ ਕਰਨਾ। ਇਸ਼ੂਅਰ ਨੂੰ ਜੋ ਵੀ ਲੋੜੀਂਦਾ ਹੈ ਸਭ ਇਕੱਠਾ ਸਫ਼ਰ ਕਰਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਹਫ਼ਤਿਆਂ ਦਾ ਰੱਦਕਰਨ ਇਤਿਹਾਸ ਵੀ ਹੈ ਜਿਸ ਨੂੰ ਕੋਈ ਯਾਦ ਨਹੀਂ ਕਿ ਉਸ ਨੇ ਲਿਖਿਆ ਸੀ।
ਮਾਡਲ B ਕੁੰਜੀ ਦੀ ਸੰਭਾਲ ਹੈ। ਕੁੰਜੀ PKCS#11 ਮਾਡਿਊਲ ਦੇ ਅੰਦਰ ਪੈਦਾ ਹੁੰਦੀ ਹੈ ਅਤੇ ਨਾ-ਕੱਢਣਯੋਗ ਵਜੋਂ ਨਿਸ਼ਾਨਿਤ ਹੁੰਦੀ ਹੈ; ਮਾਡਿਊਲ ਇਸ ਨੂੰ ਬੈਕਅਪ ਲਈ ਲਪੇਟ ਸਕਦਾ ਹੈ, ਪਰ ਕੋਈ ਵੀ ਪ੍ਰਕਿਰਿਆ ਕਦੇ ਵੀ ਕੱਚੇ ਬਾਈਟ ਨਹੀਂ ਪੜ੍ਹਦੀ। ਫਿਰ ਤੁਹਾਡਾ ਬੈਕਅਪ ਦੋ ਚੀਜ਼ਾਂ ਹਨ ਜੋ ਸਹੀ ਕ੍ਰਮ ਵਿੱਚ ਬਹਾਲ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ: ਇੱਕ ਲਪੇਟੀ ਕੁੰਜੀ ਬਲਾਬ ਜੋ ਸਿਰਫ਼ ਉਹ ਮਾਡਿਊਲ ਪਰਿਵਾਰ ਖੋਲ੍ਹ ਸਕਦਾ ਹੈ, ਅਤੇ ਡੇਟਾਬੇਸ, ਕੌਨਫਿਗਰੇਸ਼ਨ ਤੇ ਸਰਟੀਫਿਕੇਟਾਂ ਦੀ ਸਾਧਾਰਨ ਕਾਪੀ।
| Attribute | Encrypted archive | HSM key backup |
|---|---|---|
| What you store | one encrypted file | wrapped blob plus CA records |
| Who can restore it | anyone holding the passphrase | holder of the module and the blob, often vendor support |
| If a copy leaks | attacker with the passphrase becomes the CA | blob is inert without the matching module |
| What usually breaks it | forgotten passphrase, one damaged copy | replacement module rejects the blob, contract gap |
ਤੁਲਨਾ ਕਦੇ ਵੀ ਇਸ ਬਾਰੇ ਨਹੀਂ ਕਿ ਕਿਹੜਾ ਮਾਡਲ ਅਮੂਰਤ ਰੂਪ ਵਿੱਚ ਵਧੇਰੇ ਮਜ਼ਬੂਤ ਹੈ। ਇਹ ਇਸ ਬਾਰੇ ਹੈ ਕਿ ਤੁਹਾਡੀ ਟੀਮ ਰਾਤ 2 ਵਜੇ ਸੱਚਮੁੱਚ ਜਾਗਦੇ ਲੋਕਾਂ ਨਾਲ ਕਿਹੜਾ ਬਹਾਲ ਕਰ ਸਕਦੀ ਹੈ। ਜਿਸ ਆਰਕਾਈਵ ਨੂੰ ਕੋਈ ਡੀਕ੍ਰਿਪਟ ਨਹੀਂ ਕਰ ਸਕਦਾ ਅਤੇ ਜਿਸ HSM ਬਲਾਬ ਨੂੰ ਕਿਸੇ ਨੇ ਪਰਖਿਆ ਨਹੀਂ, ਦੋਵੇਂ ਬਰਾਬਰ ਬੇਕਾਰ ਹਨ। ਫ਼ਰਕ ਇਹ ਹੈ ਕਿ ਆਰਕਾਈਵ ਦੀ ਨਾਕਾਮੀ ਪਾਸਵਰਡ ਮੈਨੇਜਰ ਵਿੱਚ ਦਿਸਦੀ ਹੈ, ਅਤੇ HSM ਦੀ ਨਾਕਾਮੀ ਸਹਾਇਤਾ ਸਮਝੌਤੇ ਵਿੱਚ ਲੁਕੀ ਰਹਿੰਦੀ ਹੈ।
ਹਰ CA ਬੈਕਅਪ ਵਿੱਚ ਕੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ
ਦੋਵੇਂ ਮਾਡਲਾਂ ਨੂੰ ਉਹੀ ਰਿਕਾਰਡ ਸੈੱਟ ਚਾਹੀਦਾ ਹੈ। OpenSSL CA ਵਿੱਚ ਉਹ ਫਾਈਲਾਂ index.txt ਹਨ, ਹਰ ਜਾਰੀ ਸਰਟੀਫਿਕੇਟ ਲਈ ਇੱਕ ਕਤਾਰ ਜੋ ਸਥਿਤੀ, ਸਮਾਪਤੀ, serial ਤੇ ਵਿਸ਼ਾ ਕਵਰ ਕਰਦੀ ਹੈ, ਫਿਰ index.txt.attr, ਅਗਲਾ ਜਾਰੀ ਕਰਨ ਵਾਲਾ serial ਰੱਖਣ ਵਾਲੀ serial, ਅਗਲਾ CRL ਨੰਬਰ ਰੱਖਣ ਵਾਲੀ crlnumber, ਅਤੇ ਤੁਹਾਡੀ CA ਸੱਚਮੁੱਚ ਚੱਲਣ ਵਾਲੀ dir, policy ਤੇ default_days ਵਾਲੀ openssl.cnf। openssl-ca ਦਸਤਾਵੇਜ਼ ਦੱਸਦਾ ਹੈ ਕਿ ਇਹਨਾਂ ਵਿੱਚੋਂ ਹਰ ਕਾਊਂਟਰ ਕੀ ਨਿਯੰਤਰਿਤ ਕਰਦਾ ਹੈ। easy-rsa ਉਹੀ ਡੇਟਾ pki/ ਹੇਠ ਰੱਖਦਾ ਹੈ, ਅਤੇ vars ਫਾਈਲ ਸਰਟੀਫਿਕੇਟ ਦੇ ਖੇਤਰ ਤੈਅ ਕਰਦੀ ਹੈ।
ਕੁੰਜੀ ਅਤੇ ਸਰਟੀਫਿਕੇਟ ਉਹ ਹਿੱਸੇ ਹਨ ਜੋ ਤੁਸੀਂ ਦੁਬਾਰਾ ਨਹੀਂ ਬਣਾ ਸਕਦੇ। ਡੇਟਾਬੇਸ ਉਹ ਹਿੱਸਾ ਹੈ ਜੋ ਤੁਸੀਂ ਯਾਦ ਤੋਂ ਦੁਬਾਰਾ ਨਹੀਂ ਬਣਾ ਸਕਦੇ। index.txt ਛੱਡਣ ਨਾਲ ਵੀ ਤੁਸੀਂ ਨਵੇਂ ਸਰਟੀਫਿਕੇਟਾਂ ’ਤੇ ਦਸਤਖ਼ਤ ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ ਇਹੀ ਅਸਲ ਜਾਲ ਹੈ: ਪਹਿਲੀ ਵਾਰ ਜਦੋਂ ਗਾਹਕ ਪੁੱਛਦਾ ਹੈ ਕਿ ਸਰਟੀਫਿਕੇਟ ਰੱਦ ਹੋਇਆ ਸੀ ਜਾਂ ਨਹੀਂ, ਤੁਹਾਨੂੰ ਪਤਾ ਲੱਗਦਾ ਹੈ ਕਿ ਇਹ ਗੁੰਮ ਹੈ। CA ਦਾ ਫਿੰਗਰਪ੍ਰਿੰਟ ਬੈਕਅਪ ਤੋਂ ਬਾਹਰ ਦਰਜ ਕਰੋ, ਤਾਂ ਜੋ ਬਹਾਲੀ ਦੀ ਤੁਲਨਾ ਤੁਹਾਡੇ ਭਰੋਸੇਯੋਗ ਮੁੱਲ ਨਾਲ ਹੋਵੇ, ਹੁਣੇ ਬਹਾਲ ਕੀਤੀ ਫਾਈਲ ਨਾਲ ਨਹੀਂ।
openssl x509 -in ca.crt -noout -fingerprint -sha256
tar czf ca-state.tar.gz ca.crt ca.key index.txt* serial* crlnumber* openssl.cnf
openssl enc -aes-256-cbc -pbkdf2 -iter 200000 -salt -in ca-state.tar.gz -out ca-state.tar.gz.enc
openssl ca -config openssl.cnf -gencrl -out crl.pemਬਹਾਲੀ ਟੈਸਟ ਜੋ ਇਸ਼ੂਅਰ ਨੂੰ ਸ਼ਾਖਾਵਾਂ ਨਹੀਂ ਬਣਾਉਂਦੇ
ਇੱਕੋ ਵਿਸ਼ਾ ਅਤੇ ਇੱਕੋ ਕੁੰਜੀ ਵਾਲੇ ਦੋ ਜੀਵਤ CA ਅਸਲ ਨੂੰ ਭਰੋਸਾ ਕਰਨ ਵਾਲੇ ਹਰ ਗਾਹਕ ਲਈ ਇੱਕੋ ਜਿਹੇ ਦਿਸਦੇ ਹਨ। ਇੱਕੋ ਨੰਬਰ ਪਰ ਵੱਖਰੀ ਸਮੱਗਰੀ ਵਾਲੇ ਦੋ CRL ਉਹ ਢੰਗ ਹਨ ਜਿਸ ਨਾਲ ਗਾਹਕ ਤੁਹਾਡੇ ਰੱਦ ਕੀਤੇ ਸਰਟੀਫਿਕੇਟ ਨੂੰ ਚੁੱਪਚਾਪ ਸਵੀਕਾਰ ਕਰਦੇ ਹਨ। ਬਹਾਲੀ ਨੂੰ ਤੁਹਾਡੇ ਗਾਹਕਾਂ ਤੱਕ ਰਾਹ ਨਾ ਹੋਣ ਵਾਲੇ ਹੋਸਟ ’ਤੇ ਜਾਂ ਇੱਕ ਵਾਰ ਵਰਤੋਂ ਵਾਲੇ VM ਵਿੱਚ ਚਲਾਓ, ਅਤੇ ਟੈਸਟ ਵੱਲੋਂ ਬਣਾਈ CRL ਕਦੇ ਪ੍ਰਕਾਸ਼ਿਤ ਨਾ ਕਰੋ।
ਜਿਹੜਾ ਟੈਸਟ ਸਿਰਫ਼ ਇਹ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਆਰਕਾਈਵ ਖੁੱਲ੍ਹਦਾ ਹੈ, ਉਹ ਜਾਰੀ ਕਰਨ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਸਾਬਤ ਕਰਦਾ। ਜਿਹੜਾ ਕ੍ਰਮ ਮਾਇਨੇ ਰੱਖਦਾ ਹੈ: ਬਹਾਲ ਕੀਤੀ ca.crt ਦਾ ਫਿੰਗਰਪ੍ਰਿੰਟ ਤੁਹਾਡੇ ਦਰਜ ਮੁੱਲ ਨਾਲ ਤੁਲਨਾ ਕਰੋ, serial ਤੁਹਾਡੇ ਆਖ਼ਰੀ ਜਾਰੀ ਸਰਟੀਫਿਕੇਟ ਦੇ ਸੰਕੇਤ ਨਾਲ ਮਿਲਦਾ ਹੈ ਇਹ ਪੱਕਾ ਕਰੋ, ਇੱਕ ਵਾਰ ਵਰਤੋਂ ਵਾਲੇ CN ਲਈ ਇੱਕ ਸਰਟੀਫਿਕੇਟ ਜਾਰੀ ਕਰੋ ਅਤੇ index.txt ਇੱਕ ਕਤਾਰ ਪਾਉਂਦੀ ਦੇਖੋ, ਫਿਰ ਉਹ ਸਰਟੀਫਿਕੇਟ ਰੱਦ ਕਰੋ ਅਤੇ CRL ਦੁਬਾਰਾ ਬਣਾਓ।
openssl verify -CAfile ca.crt -CRLfile crl.pem -crl_check client.crt
openssl crl -in crl.pem -noout -lastupdate -nextupdateHSM ਨਾਲ ਉਹੀ ਟੈਸਟ ਮਾਡਿਊਲ ਰਾਹੀਂ ਜਾਂਦਾ ਹੈ। ਬਲਾਬ ਨੂੰ ਬਦਲਵੇਂ ਜੰਤਰ ਵਿੱਚ ਖੋਲ੍ਹੋ, ਮਾਡਿਊਲ ਵੱਲੋਂ ਦੱਸਿਆ CA ਸਰਟੀਫਿਕੇਟ ਤੁਹਾਡੇ ਦਰਜ ਫਿੰਗਰਪ੍ਰਿੰਟ ਨਾਲ ਮਿਲਦਾ ਹੈ ਇਹ ਪੱਕਾ ਕਰੋ, ਅਤੇ ਫਿਰ ਹੀ ਇਸ ਨੂੰ ਦਸਤਖ਼ਤ ਕਰਨ ਦਿਓ। ਜੇ ਮਾਡਿਊਲ ਦਾ ਆਪਣਾ ਆਬਜੈਕਟ ਸਟੋਰ ਹੈ, ਲਪੇਟਣ ਨੂੰ ਕੁੰਜੀ ਆਬਜੈਕਟ ਅਤੇ ਉਸ ਦੇ ਲੇਬਲ ਨੂੰ ਕਵਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਕਿਉਂਕਿ ਵੱਖਰੇ ਲੇਬਲ ਹੇਠ ਕੁੰਜੀ ਬਹਾਲ ਕਰਨ ਨਾਲ ਉਸ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਨ ਵਾਲੀ ਕੌਨਫਿਗਰੇਸ਼ਨ ਟੁੱਟ ਜਾਂਦੀ ਹੈ।
ਨਾਕਾਮੀ ਦੇ ਢੰਗ ਜੋ ਚੋਣ ਤੈਅ ਕਰਦੇ ਹਨ
ਪੰਜ ਨਾਕਾਮੀਆਂ ਜ਼ਿਆਦਾਤਰ ਅਸਲ ਨੁਕਸਾਨਾਂ ਦੀ ਵਿਆਖਿਆ ਕਰਦੀਆਂ ਹਨ। ਭੇਤ ਦੀ ਸੁਤੰਤਰ ਕਾਪੀ ਤੋਂ ਬਿਨਾਂ ਭੁੱਲਿਆ ਆਰਕਾਈਵ ਪਾਸਫਰੇਜ਼ ਆਰਕਾਈਵ ਨੂੰ ਇੱਟ ਬਣਾ ਦਿੰਦਾ ਹੈ। ਇੱਕ ਡਿਸਕ ’ਤੇ ਇੱਕੋ ਕਾਪੀ ਉਸ ਡਿਸਕ ਨਾਲ ਮਰ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਚੈੱਕਸਮ ਕਦੇ ਨਹੀਂ ਦੱਸਦਾ ਕਿ ਡੀਕ੍ਰਿਪਸ਼ਨ ਅਜੇ ਕੰਮ ਕਰਦਾ ਹੈ ਜਾਂ ਨਹੀਂ। ਬੈਕਅਪ ਤਾਰੀਖ਼ ਤੋਂ ਬਾਅਦ ਰੱਦ ਕੀਤੇ ਸਰਟੀਫਿਕੇਟ ਬਹਾਲੀ ਤੋਂ ਬਾਅਦ ਫਿਰ ਵੈਧ ਦਿਸਦੇ ਹਨ, ਇਸ ਲਈ ਤੁਹਾਡਾ ਬੈਕਅਪ ਅੰਤਰਾਲ ਹੀ ਤੁਹਾਡਾ ਰੱਦਕਰਨ ਦਾ ਅੰਨ੍ਹਾ ਧੱਬਾ ਹੈ। ਪੁਰਾਣਾ serial ਕਾਊਂਟਰ ਬਹਾਲ ਕਰਨ ਨਾਲ serial ਨੰਬਰ ਦੁਬਾਰਾ ਵਰਤੇ ਜਾਂਦੇ ਹਨ ਅਤੇ serial-ਆਧਾਰਿਤ ਕੈਸ਼ ਤੇ CRL ਖੋਜਾਂ ਉਲਝ ਜਾਂਦੀਆਂ ਹਨ। ਲਪੇਟੀ ਬਲਾਬ ਨੂੰ ਰੱਦ ਕਰਨ ਵਾਲਾ ਬਦਲਵਾਂ HSM ਹਾਰਡਵੇਅਰ ਬਦਲੀ ਨੂੰ ਪੂਰੀ ਮੁੜ-ਜਾਰੀ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ।
ਮਾਡਲ A ਪਹਿਲੇ ਚਾਰ ਨਾਲ ਮਾੜੇ ਪਰ ਦਿਸਣ ਵਾਲੇ ਢੰਗ ਨਾਲ ਨਜਿੱਠਦਾ ਹੈ। ਮਾਡਲ B ਉਹਨਾਂ ਨਾਲ ਚੰਗੀ ਤਰ੍ਹਾਂ ਨਜਿੱਠਦਾ ਹੈ ਜਦ ਤੱਕ ਮਾਡਿਊਲ ਜਾਂ ਵਿਕਰੇਤਾ ਦੀ ਪ੍ਰਕਿਰਿਆ ਫੇਲ੍ਹ ਨਹੀਂ ਹੁੰਦੀ। ਜੇ ਤੁਹਾਡੀਆਂ ਕੁੰਜੀਆਂ ਨਿਰਯਾਤਯੋਗ ਹਨ ਅਤੇ ਟੀਮ ਛੋਟੀ ਹੈ, ਐਨਕ੍ਰਿਪਟਿਡ ਆਰਕਾਈਵ ਇਮਾਨਦਾਰ ਚੋਣ ਹੈ, ਦੋ ਮਾਧਿਅਮਾਂ ਅਤੇ ਲਿਖਤੀ ਪਾਸਫਰੇਜ਼ ਕਾਰਵਾਈ ਦੇ ਸਹਾਰੇ। ਜੇ ਕੁੰਜੀ ਨਾ-ਕੱਢਣਯੋਗ ਹੈ ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਕੋਈ ਚੋਣ ਨਹੀਂ, ਅਤੇ ਕੰਮ ਉਸ ਦਿਨ ਤੋਂ ਪਹਿਲਾਂ ਵਿਕਰੇਤਾ ਦੇ ਬਹਾਲੀ ਰਾਹ ਨੂੰ ਸਾਬਤ ਕਰਨ ਵੱਲ ਚਲਾ ਜਾਂਦਾ ਹੈ ਜਿਸ ਦਿਨ ਤੁਹਾਨੂੰ ਇਸ ਦੀ ਲੋੜ ਹੋਵੇਗੀ।
ਮਾਡਲ ਚੁਣਨਾ ਅਤੇ ਸਮਾਂ-ਸਾਰਣੀ
ਤਿੰਨ ਸ਼ਰਤਾਂ ਫੈਸਲਾ ਤੈਅ ਕਰਦੀਆਂ ਹਨ। ਕੀ ਵਿਕਰੇਤਾ ਦੀ ਪ੍ਰਕਿਰਿਆ ਤੋਂ ਬਿਨਾਂ ਕੁੰਜੀ ਨਿਰਯਾਤ ਹੋ ਸਕਦੀ ਹੈ? ਕੀ ਬਹਾਲੀ ਉਸ ਹਾਰਡਵੇਅਰ ’ਤੇ ਉਤਰਨੀ ਚਾਹੀਦੀ ਹੈ ਜੋ ਤੁਹਾਡੇ ਕੋਲ ਪਹਿਲਾਂ ਤੋਂ ਨਹੀਂ? ਸਹਾਇਤਾ ਨਾਲ ਬਹਿਸ ਕਰਦਿਆਂ ਜਾਰੀ ਕਰਨਾ ਕਿੰਨਾ ਚਿਰ ਰੁਕ ਸਕਦਾ ਹੈ? ਇਹਨਾਂ ਤਿੰਨਾਂ ਦਾ ਜਵਾਬ ਦਿਓ ਅਤੇ ਮਾਡਲ ਤੈਅ ਹੋ ਜਾਂਦਾ ਹੈ; ਉਸ ਤੋਂ ਬਾਅਦ ਸਭ ਕੁਝ ਸਮਾਂ-ਸਾਰਣੀ ਹੈ।
ਹਰ ਦਸਤਖ਼ਤ ਸਮਾਰੋਹ ਤੋਂ ਬਾਅਦ ਅਤੇ ਕਿਸੇ ਵੀ ਕੌਨਫਿਗਰੇਸ਼ਨ ਤਬਦੀਲੀ ਤੋਂ ਪਹਿਲਾਂ ਬੈਕਅਪ ਲਓ, ਕਿਉਂਕਿ ਕੌਨਫਿਗਰੇਸ਼ਨ ਹਾਲਤ ਦਾ ਹਿੱਸਾ ਹੈ। ਵੱਖਰੀਆਂ ਥਾਵਾਂ ’ਤੇ ਵੱਖਰੇ ਮਾਧਿਅਮਾਂ ’ਤੇ ਦੋ ਕਾਪੀਆਂ ਰੱਖੋ, ਇੱਕ ਆਫ਼ਲਾਈਨ, ਅਤੇ ਡੀਕ੍ਰਿਪਸ਼ਨ ਭੇਤ ਨੂੰ ਕਾਪੀਆਂ ਤੋਂ ਵੱਖਰੇ ਭਰੋਸਾ ਡੋਮੇਨ ਵਿੱਚ ਰੱਖੋ। ਬੈਕਅਪ ਰਿਕਾਰਡ ’ਤੇ ਆਖ਼ਰੀ ਸਫਲ ਬਹਾਲੀ ਦੀ ਤਾਰੀਖ਼ ਲਿਖੋ। ਜਿਹੜਾ ਬੈਕਅਪ ਕਦੇ ਬਹਾਲ ਨਹੀਂ ਹੋਇਆ ਉਹ ਧਾਰਨਾ ਹੈ, ਨਿਯੰਤਰਣ ਨਹੀਂ।
ਟਿਕਟ ਬੰਦ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇਹ ਪੰਜ ਨੁਕਤੇ ਪੱਕੇ ਕਰੋ:
- ca.crt ਦਾ ਫਿੰਗਰਪ੍ਰਿੰਟ ਬੈਕਅਪ ਤੋਂ ਬਾਹਰ ਕਿਤੇ ਦਰਜ ਹੈ।
- index.txt, serial, crlnumber ਅਤੇ openssl.cnf ਸਾਰੇ ਆਰਕਾਈਵ ਜਾਂ ਬਲਾਬ ਸੈੱਟ ਦੇ ਅੰਦਰ ਹਨ।
- ਪਾਸਫਰੇਜ਼ ਜਾਂ ਲਪੇਟੀ ਕੁੰਜੀ ਦੀ ਸੰਭਾਲ ਦਰਜ ਹੈ ਅਤੇ ਆਰਕਾਈਵ ਮਾਲਕ ਤੋਂ ਇਲਾਵਾ ਕਿਸੇ ਹੋਰ ਕੋਲ ਹੈ।
- ਅਲੱਗ ਹੋਸਟ ’ਤੇ ਇੱਕ ਜਾਰੀ ਅਤੇ ਇੱਕ ਰੱਦਕਰਨ ਨਾਲ ਬਹਾਲੀ ਦੀ ਪਰਖ ਕੀਤੀ ਗਈ ਹੈ।
- ਤੁਹਾਡੇ ਬੈਕਅਪ ਅੰਤਰਾਲ ਵੱਲੋਂ ਦਰਸਾਇਆ ਰੱਦਕਰਨ ਦਾ ਪਾੜਾ ਲਿਖਤੀ ਰੂਪ ਵਿੱਚ ਸਵੀਕਾਰਿਆ ਜਾਂ ਘਟਾਇਆ ਗਿਆ ਹੈ।