ਆਪਣੇ VPN ਰੂਟ CA ਨੂੰ ਔਫਲਾਈਨ ਰੱਖੋ ਅਤੇ ਫਿਰ ਵੀ ਸਰਟੀਫਿਕੇਟ ਜਾਰੀ ਕਰੋ

ਤੁਹਾਡਾ VPN ਰਾਤ 3 ਵਜੇ ਕਨੈਕਸ਼ਨਾਂ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਇਸਦੇ ਸਰਟੀਫਿਕੇਟ ਸਾਈਨ ਕਰਨ ਵਾਲੀ ਮਸ਼ੀਨ ਦਰਾਜ਼ ਵਿੱਚ ਬੰਦ ਪਈ ਹੁੰਦੀ ਹੈ। ਸਰਵਰ ਸਰਟੀਫਿਕੇਟ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਵਾਲਾ ਕਲਾਇੰਟ ਕਦੇ ਵੀ ਤੁਹਾਡੇ CA ਨਾਲ ਸੰਪਰਕ ਨਹੀਂ ਕਰਦਾ, ਇਸ ਲਈ ਕਿਸੇ ਵੀ ਕਨੈਕਸ਼ਨ ਲਈ CA ਦਾ ਪਹੁੰਚਯੋਗ ਹੋਣਾ ਜ਼ਰੂਰੀ ਨਹੀਂ। ਜਿਸ ਹਿੱਸੇ ਲਈ ਯੋਜਨਾ ਲੋੜੀਂਦੀ ਹੈ ਉਹ ਹੈ ਉਹ ਦਿਨ ਜਦੋਂ ਸਰਟੀਫਿਕੇਟ ਜਾਰੀ, ਨਵੀਨੀਕਰਨ ਜਾਂ ਰੱਦ ਕਰਨਾ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਰੂਟ ਕੁੰਜੀ ਤਾਲੇ ਹੇਠ ਰਹਿੰਦੀ ਹੈ।

ਕਨੈਕਸ਼ਨ ਅਸਲ ਵਿੱਚ ਕੀ ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ

ਜਦੋਂ OpenVPN ਕਲਾਇੰਟ ਜੁੜਦਾ ਹੈ, ਤਾਂ ਇਹ ਸਰਵਰ ਦੇ ਪੱਤਾ ਸਰਟੀਫਿਕੇਟ ਤੋਂ ਉੱਪਰ ਉਸ CA ਸਰਟੀਫਿਕੇਟ ਤੱਕ ਸਾਈਨ ਚੇਨ ਰਾਹੀਂ ਜਾਂਦਾ ਹੈ ਜਿਸ ’ਤੇ ਇਹ ਪਹਿਲਾਂ ਹੀ ਭਰੋਸਾ ਕਰਦਾ ਹੈ, ਵੈਧਤਾ ਦੀ ਮਿਆਦ ਜਾਂਚਦਾ ਹੈ ਅਤੇ ਜੇ ਪ੍ਰੋਫਾਈਲ ਕਹੇ ਤਾਂ ਰੱਦ ਕਰਨ ਦੀ ਸੂਚੀ ਵੇਖਦਾ ਹੈ। ਇਹ ਕਦੇ ਵੀ ਤੁਹਾਡੇ ਰੂਟ CA ਨੂੰ ਨਹੀਂ ਲੱਭਦਾ। ਸਰਵਰ ਕਲਾਇੰਟ ਸਰਟੀਫਿਕੇਟਾਂ ਲਈ ਸ਼ੀਸ਼ੇ ਵਾਂਗ ਕੰਮ ਕਰਦਾ ਹੈ। ਜੁੜਨ ਦੇ ਸਮੇਂ ਸਿਰਫ਼ ਪੱਤਾ, ਵਿਚਕਾਰਲਾ ਅਤੇ ਪਹਿਲਾਂ ਵੰਡਿਆ ਭਰੋਸਾ ਬੰਡਲ ਮੌਜੂਦ ਹੁੰਦੇ ਹਨ।

ਅਸਲ ਵਿੱਚ ਤਿੰਨਾਂ ਵਿੱਚੋਂ ਇੱਕ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ: ਜਾਰੀ ਕਰਨ ਵੇਲੇ ਸਾਈਨ ਕੁੰਜੀ ਉਪਲਬਧ ਨਹੀਂ ਹੁੰਦੀ, ਰੱਦ ਕਰਨ ਦੀ ਸੂਚੀ ਪੁਰਾਣੀ ਹੋ ਗਈ ਹੈ, ਜਾਂ ਕਲਾਇੰਟ ਦਾ ਭਰੋਸਾ ਬੰਡਲ ਸਰਵਰ ਵੱਲੋਂ ਪੇਸ਼ ਕੀਤੀ ਚੇਨ ਤੋਂ ਪੁਰਾਣਾ ਹੈ। ਪਹਿਲਾ ਪ੍ਰਕਿਰਿਆ ਦੀ ਸਮੱਸਿਆ ਹੈ; ਬਾਕੀ ਦੋ ਵੰਡ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਹਨ। ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਰੂਟ ਕੁੰਜੀ ਦੇ ਆਨਲਾਈਨ ਹੋਣ ਦੀ ਮੰਗ ਨਹੀਂ ਕਰਦਾ, ਅਤੇ ਟਨਲ ਪ੍ਰਮਾਣੀਕਰਨ ਲਈ ਪ੍ਰਾਈਵੇਟ ਸਰਟੀਫਿਕੇਟ ਮੰਗਣ ਵਾਲੀ ਪ੍ਰਬੰਧਿਤ VPN ਸੇਵਾ ਸਿਰਫ਼ ਸਾਈਨ ਅਧਿਕਾਰ ਪ੍ਰਦਾਤਾ ਨੂੰ ਭੇਜਦੀ ਹੈ। Azure ਪੁਆਇੰਟ-ਟੂ-ਸਾਈਟ ਉਲਟਾ ਕੰਮ ਕਰਦਾ ਹੈ: ਤੁਸੀਂ ਰੂਟ ਸਰਟੀਫਿਕੇਟ ਅੱਪਲੋਡ ਕਰਦੇ ਹੋ ਅਤੇ ਉਸ ਹੇਠ ਸਾਈਨ ਕੀਤੇ ਸਰਟੀਫਿਕੇਟ ਭਰੋਸੇਯੋਗ ਮੰਨੇ ਜਾਂਦੇ ਹਨ, ਇਸ ਲਈ ਪੁੱਛੋ ਕੌਣ ਸਾਈਨ ਕਰਦਾ ਹੈ, ਕੌਣ ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ ਅਤੇ ਸਰਟੀਫਿਕੇਟ ਸਮੇਂ ਤੋਂ ਪਹਿਲਾਂ ਕਿਵੇਂ ਵਾਪਸ ਲਿਆ ਜਾਂਦਾ ਹੈ।

ਰੂਟ ਨੂੰ ਅਜਿਹੇ ਹੋਸਟ ’ਤੇ ਬਣਾਓ ਜਿਸਨੂੰ ਕਦੇ ਪਤਾ ਨਹੀਂ ਮਿਲਦਾ

ਔਫਲਾਈਨ ਰੂਟ ਦੀ ਵਰਤੋਂ ਘੱਟ ਹੀ ਹੁੰਦੀ ਹੈ: ਵਿਚਕਾਰਲੇ CA ਸਰਟੀਫਿਕੇਟ ਨੂੰ ਸਾਈਨ ਕਰਨ ਲਈ, ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਇਸਨੂੰ ਨਵੀਨੀਕਰਨ ਜਾਂ ਰੱਦ ਕਰਨ ਲਈ। ਬਾਕੀ ਸਭ ਕੁਝ ਇੱਕ ਪੱਧਰ ਹੇਠਾਂ ਹੁੰਦਾ ਹੈ। ਰੂਟ ਦਾ ਕੰਮ ਨੈੱਟਵਰਕ ਤੋਂ ਦੂਰ ਰੱਖੀ ਮਸ਼ੀਨ ’ਤੇ, ਸੰਭਵ ਹੋਵੇ ਤਾਂ ਲਾਈਵ ਸਿਸਟਮ ਤੋਂ ਕਰੋ ਅਤੇ ਕਮਰੇ ਵਿੱਚ ਕੌਣ ਸੀ ਲਿਖੋ। ਕਮਾਂਡਾਂ OpenSSL 1.1.1 ਜਾਂ ਨਵਾਂ ਮੰਨਦੀਆਂ ਹਨ, ਕਿਉਂਕਿ ਪੁਰਾਣੇ ਬਿਲਡਾਂ ਵਿੱਚ -addext ਨਹੀਂ ਹੈ।

openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out root.key
openssl req -x509 -new -key root.key -sha256 -days 7300 \
  -subj "/CN=Example VPN Root CA" -out root.crt \
  -addext "basicConstraints=critical,CA:TRUE" \
  -addext "keyUsage=critical,keyCertSign,cRLSign"

ਸਾਈਨ ਹੋਸਟ ’ਤੇ ਵਿਚਕਾਰਲਾ ਬਣਾਓ ਅਤੇ ਸਿਰਫ਼ ਇਸਦੀ ਬੇਨਤੀ ਔਫਲਾਈਨ ਮਸ਼ੀਨ ਕੋਲ ਲੈ ਜਾਓ। ਰੂਟ ਉਸ ਬੇਨਤੀ ਨੂੰ ਜ਼ੀਰੋ ਪਾਥ ਲੰਬਾਈ ਨਾਲ ਸਾਈਨ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਵਿਚਕਾਰਲਾ CA ਅੰਤ ਬਿੰਦੂ ਸਰਟੀਫਿਕੇਟ ਸਾਈਨ ਕਰ ਸਕਦਾ ਹੈ ਪਰ ਆਪਣੇ ਹੇਠਾਂ ਹੋਰ CA ਨਹੀਂ ਬਣਾ ਸਕਦਾ। ਉਹ ਇੱਕ ਐਕਸਟੈਂਸ਼ਨ ਸਮਝੌਤਾ ਹੋਏ ਸਾਈਨ ਹੋਸਟ ਨੂੰ ਰੂਟ ਦੇ ਬਰਾਬਰ ਅਧਿਕਾਰ ਬਣਾਉਣ ਤੋਂ ਰੋਕਦਾ ਹੈ। ECDSA ਸਿਰਫ਼ ਤਦ ਵਰਤੋ ਜਦੋਂ ਹਰ ਕਲਾਇੰਟ OpenVPN 2.4 ਜਾਂ ਨਵਾਂ ਚਲਾਉਂਦਾ ਹੋਵੇ; ਨਹੀਂ ਤਾਂ RSA ਕੁੰਜੀਆਂ ਬਣਾਓ ਅਤੇ ਪ੍ਰਵਾਹ ਉਹੀ ਰੱਖੋ।

openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out intermediate.key
openssl req -new -key intermediate.key -subj "/CN=Example VPN Intermediate CA" -out intermediate.csr
openssl x509 -req -in intermediate.csr -CA root.crt -CAkey root.key \
  -CAcreateserial -days 3650 -sha256 -extfile intermediate.ext -out intermediate.crt

intermediate.ext ਵਿੱਚ basicConstraints=critical,CA:TRUE,pathlen:0, keyUsage=critical,keyCertSign,cRLSign ਅਤੇ authorityKeyIdentifier=keyid:always ਹਨ। ਸਾਈਨ ਹੋਸਟ ਦੇ ਦੁਬਾਰਾ ਜੁੜਨ ਤੋਂ ਪਹਿਲਾਂ ਰੂਟ ਕੁੰਜੀ ਨੂੰ ਇਸਦੀ ਤਿਜੋਰੀ ਵਿੱਚ ਵਾਪਸ ਰੱਖੋ। ਜੇ ਰੂਟ ਨੂੰ ਵਿਚਕਾਰਲਾ ਰੱਦ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਤਾਂ ਇਸਨੂੰ openssl x509 -req ਦੀ ਥਾਂ ਰੂਟ-ਪੱਧਰੀ index.txt ਵਿਰੁੱਧ openssl ca -config root.cnf -extensions intermediate_ca ਨਾਲ ਸਾਈਨ ਕਰੋ, ਤਾਂ ਜੋ ਸੀਰੀਅਲ ਨੰਬਰ ਦਰਜ ਹੋਵੇ; ਫਿਰ ਨਤੀਜਾ ਰੂਟ ਸੂਚੀ ਕਲਾਇੰਟ ਪ੍ਰੋਫਾਈਲ ਅੰਦਰ ਭੇਜੋ, ਜਿੱਥੇ ਫਾਈਲ-ਆਧਾਰਿਤ crl-verify ਸ਼ੁਰੂ ਵਿੱਚ ਇਸਨੂੰ ਪੜ੍ਹਦਾ ਹੈ। ਕਲਾਇੰਟਾਂ ਨੂੰ ਦੋਵੇਂ CA ਸਰਟੀਫਿਕੇਟ ਵਾਲਾ ਬੰਡਲ ਭੇਜੋ; ਸਿਰਫ਼ ਪੱਤਾ ਰੂਟ ਵਿਰੁੱਧ ਪੁਸ਼ਟੀ ਨਹੀਂ ਹੋਵੇਗਾ।

ਵਿਚਕਾਰਲੇ ਤੋਂ ਪੱਤੇ ਜਾਰੀ ਕਰੋ, ਡੇਟਾਬੇਸ ਨਾਲ

openssl x509 -req ਨਾਲ ਸਾਈਨ ਕਰਨਾ ਉਦੋਂ ਤੱਕ ਕੰਮ ਕਰਦਾ ਹੈ ਜਦੋਂ ਤੱਕ ਰੱਦ ਕਰਨ ਦੀ ਲੋੜ ਨਾ ਪਵੇ, ਕਿਉਂਕਿ ਕੁਝ ਵੀ ਸੀਰੀਅਲ ਨੰਬਰ ਦਰਜ ਨਹੀਂ ਕਰਦਾ। ਪਹਿਲੇ ਸਰਟੀਫਿਕੇਟ ਤੋਂ openssl ca ਵਰਤੋ ਤਾਂ ਜੋ ਸੀਰੀਅਲ ਨੰਬਰ, ਮਿਆਦ ਅਤੇ ਰੱਦ ਸਥਿਤੀ ਇੱਕੋ ਡੇਟਾਬੇਸ ਵਿੱਚ ਰਹਿਣ। ਡੇਟਾਬੇਸ ਫਾਈਲਾਂ ਇੱਕ ਵਾਰ ਬਣਾਓ, ਫਿਰ ਕਨਫਿਗਰੇਸ਼ਨ ਉਨ੍ਹਾਂ ਵੱਲ ਮੋੜੋ:

mkdir -p /etc/vpn-ca/intermediate/newcerts
touch /etc/vpn-ca/intermediate/index.txt
echo 1000 > /etc/vpn-ca/intermediate/serial
echo 1000 > /etc/vpn-ca/intermediate/crlnumber

[ ca ]
default_ca = CA_default
[ CA_default ]
dir = /etc/vpn-ca/intermediate
database = $dir/index.txt
new_certs_dir = $dir/newcerts
serial = $dir/serial
crlnumber = $dir/crlnumber
certificate = $dir/intermediate.crt
private_key = $dir/intermediate.key
default_md = sha256
default_days = 365
default_crl_days = 30
unique_subject = no
policy = policy_any
[ policy_any ]
commonName = supplied
[ server_cert ]
basicConstraints = CA:FALSE
keyUsage = critical, digitalSignature
extendedKeyUsage = serverAuth
subjectAltName = @server_names
[ client_cert ]
basicConstraints = CA:FALSE
keyUsage = critical, digitalSignature
extendedKeyUsage = clientAuth
[ server_names ]
DNS.1 = vpn.example.com

ਕੁੰਜੀ ਵਰਤੋਂ ਦੀ ਲਾਈਨ ECDSA ਕੁੰਜੀ ਮੰਨਦੀ ਹੈ; RSA ਲਈ keyEncipherment ਸ਼ਾਮਲ ਕਰੋ। ਹਰ ਕਲਾਇੰਟ ਨੂੰ ਆਪਣਾ ਆਮ ਨਾਮ ਦਿਓ, ਕਿਉਂਕਿ OpenVPN ਉਸ ਫੀਲਡ ਤੋਂ ਕਨੈਕਸ਼ਨ ਪਛਾਣਦਾ ਹੈ, ਅਤੇ CN=vpn-client ਸਾਂਝਾ ਕਰਨ ਵਾਲੇ ਦੋ ਲੈਪਟਾਪ ਲੌਗਾਂ ਵਿੱਚ, client-config-dir ਨਿਯਮਾਂ ਵਿੱਚ ਜਾਂ ਕਿਸੇ ਵੀ ਵਰਤੋਂਕਾਰ-ਵਿਸ਼ੇਸ਼ ਪੁਸ਼ ਵਿੱਚ ਵੱਖ ਨਹੀਂ ਕੀਤੇ ਜਾ ਸਕਦੇ, ਅਤੇ ਤੁਸੀਂ ਉਹ ਐਟਰਿਬਿਊਸ਼ਨ ਗੁਆ ਦਿੰਦੇ ਹੋ ਜੋ ਰੱਦ ਕਰਨ ਦੇ ਫੈਸਲੇ ਨੂੰ ਬਚਾਉਣਯੋਗ ਬਣਾਉਂਦਾ ਹੈ। ਪੱਤਾ ਇਸ ਤਰ੍ਹਾਂ ਜਾਰੀ ਕਰੋ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ:

openssl req -new -key alice.key -subj "/CN=alice-laptop" -out alice.csr
openssl ca -config intermediate.cnf -extensions client_cert -in alice.csr -out alice.crt -batch
openssl verify -CAfile ca-bundle.crt -untrusted intermediate.crt alice.crt

ਸਾਈਨ ਕੁੰਜੀ ਨੂੰ VPN ਹੋਸਟ ’ਤੇ ਕਾਪੀ ਕਰਨ ਦੀ ਥਾਂ ਨੀਤੀ ਸੀਮਾ ਪਿੱਛੇ ਰੱਖੋ: ਇੱਕ ਛੋਟੀ ਸੇਵਾ ਜੋ ਬੇਨਤੀ ਦੀ ਪ੍ਰਮਾਣਿਕਤਾ ਜਾਂਚਦੀ ਹੈ, ਆਮ ਨਾਮ ਨੂੰ ਮਨਜ਼ੂਰ ਸੂਚੀ ਵਿਰੁੱਧ ਜਾਂਚਦੀ ਹੈ ਅਤੇ ਸਿਰਫ਼ ਸਰਟੀਫਿਕੇਟ ਵਾਪਸ ਕਰਦੀ ਹੈ। ਹਰ ਸੀਰੀਅਲ ਨੰਬਰ ਦਰਜ ਕਰੋ; ਲੌਗ ਹੀ ਸਰਟੀਫਿਕੇਟ ਅਤੇ ਇਸਨੂੰ ਮੰਗਣ ਵਾਲੇ ਵਿਅਕਤੀ ਵਿਚਕਾਰ ਇੱਕੋ ਕੜੀ ਹੈ।

ਰੂਟ ਨੂੰ ਜਗਾਏ ਬਿਨਾਂ ਰੱਦ ਕਰਨ ਦੀ ਸੂਚਨਾ ਦਿਓ

ਕਲਾਇੰਟ ਸਰਟੀਫਿਕੇਟ ਵਿਚਕਾਰਲਾ ਰੱਦ ਕਰਦਾ ਹੈ, ਕਦੇ ਵੀ ਰੂਟ ਨਹੀਂ। ਰੂਟ ਸੂਚੀ ਸਿਰਫ਼ ਤਦ ਮਹੱਤਵਪੂਰਨ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਕੋਈ ਵਿਚਕਾਰਲਾ ਸੜ ਜਾਵੇ। ਸਰਵਰ ਨੂੰ crl-verify ਨਾਲ ਵਿਚਕਾਰਲੀ ਸੂਚੀ ਵੱਲ ਮੋੜੋ। ਫਾਈਲ-ਆਧਾਰਿਤ CRL ਸੇਵਾ ਸ਼ੁਰੂ ਹੁੰਦਿਆਂ ਲੋਡ ਹੁੰਦਾ ਹੈ, ਇਸ ਲਈ ਹਰ ਮੁੜ-ਨਿਰਮਾਣ ਤੋਂ ਬਾਅਦ ਦੁਬਾਰਾ ਲੋਡ ਕਰੋ; ਡਾਇਰੈਕਟਰੀ ਰੂਪ ਜੁੜਨ ਵੇਲੇ ਸਥਿਤੀ ਪੜ੍ਹਦਾ ਹੈ ਅਤੇ ਹਰ ਸੀਰੀਅਲ ਲਈ ਇੱਕ ਫਾਈਲ ਖਰਚ ਕਰਦਾ ਹੈ।

ਉਸੇ ਡੇਟਾਬੇਸ ਤੋਂ ਦੋ ਕਮਾਂਡਾਂ ਨਾਲ ਰੱਦ ਕਰੋ ਅਤੇ ਮੁੜ ਬਣਾਓ:

openssl ca -config intermediate.cnf -revoke /etc/vpn-ca/intermediate/newcerts/1001.pem
openssl ca -config intermediate.cnf -gencrl -out /etc/openvpn/crl.pem

ਫਿਰ ਘੜੀ ਵੱਲ ਧਿਆਨ ਦਿਓ। CRL ਵਿੱਚ ਅਗਲੇ ਅੱਪਡੇਟ ਦਾ ਖੇਤਰ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਉਹ ਤਾਰੀਖ਼ ਲੰਘਣ ਤੋਂ ਬਾਅਦ ਪੁਸ਼ਟੀ ਕਰਨ ਵਾਲਾ ਧਿਰ ਸੂਚੀ ਨੂੰ ਅਣਡਿੱਠ ਕਰਨ ਦੀ ਬਜਾਏ ਰੱਦ ਕਰਦਾ ਹੈ। default_crl_days = 30 ਨਾਲ ਮਹੀਨਾਵਾਰ ਮੁੜ-ਨਿਰਮਾਣ ਕੁਝ ਖੁੱਲ੍ਹ ਛੱਡਦਾ ਹੈ; ਸਾਲਾਨਾ ਨਹੀਂ। ਛੋਟੀ ਪੱਤਾ ਉਮਰ ਵਧੇਰੇ ਭਰੋਸੇਯੋਗ ਨਿਯੰਤਰਣ ਹੈ, ਕਿਉਂਕਿ ਰੱਦ ਕਰਨਾ ਸਿਰਫ਼ ਉੱਥੇ ਲਾਗੂ ਹੁੰਦਾ ਹੈ ਜਿੱਥੇ ਸੂਚੀ ਵੇਖੀ ਜਾਂਦੀ ਹੈ।

ਚੇਨ ਦੀ ਜਾਂਚ ਕਰੋ, ਫਿਰ ਰਸਮ ਲਿਖੋ

ਡਿਜ਼ਾਈਨ ’ਤੇ ਭਰੋਸਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਚਾਰ ਅਸਫਲਤਾਵਾਂ ਦੁਹਰਾਓ। openssl verify -CAfile ca-bundle.crt -untrusted intermediate.crt server.crt ਨਾਲ ਚੇਨ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ। ਸਮਾਂ ਬੀਤੇ ਕਲਾਇੰਟ ਸਰਟੀਫਿਕੇਟ ਨਾਲ ਜੁੜੋ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਸਰਵਰ ਇਸਨੂੰ ਰੱਦ ਕਰਦਾ ਹੈ। ਟੈਸਟ ਕਲਾਇੰਟ ਰੱਦ ਕਰੋ, ਦੁਬਾਰਾ ਲੋਡ ਕਰੋ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਸੂਚੀ ਲਾਗੂ ਹੁੰਦੀ ਹੈ। ਹੋਸਟ ਦੀ ਘੜੀ ਇੱਕ ਦਿਨ ਅੱਗੇ ਵਧਾਓ, ਕਿਉਂਕਿ ਗਲਤ ਘੜੀ ਹੋਰ ਕਿਤੇ ਵੈਧ ਦਿਖਣ ਵਾਲੇ ਸਰਟੀਫਿਕੇਟ ਜਾਰੀ ਅਤੇ ਰੱਦ ਕਰ ਸਕਦੀ ਹੈ।

ਔਫਲਾਈਨ ਰੂਟ ਸਿਰਫ਼ ਤਦ ਨਿਯੰਤਰਣ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਕਾਗਜ਼ਾਤ ਮੌਜੂਦ ਹੋਣ: ਰਸਮ ਲਈ ਦੋ ਨਾਮਜ਼ਦ ਵਿਅਕਤੀ, ਹਰ ਸਾਈਨ ਕੀਤੇ ਸੀਰੀਅਲ ਦਾ ਰਿਕਾਰਡ, ਮਸ਼ੀਨ ਤੋਂ ਵੱਖ ਰੱਖਿਆ ਐਨਕ੍ਰਿਪਟਿਡ ਬੈਕਅੱਪ, ਅਤੇ ਅਲੱਗ ਹੋਸਟ ’ਤੇ ਬਹਾਲੀ ਦੀ ਜਾਂਚ। ਉਸੇ ਰਸਮ ਵਿੱਚ ਇੱਕ ਵਾਧੂ ਵਿਚਕਾਰਲਾ ਸਾਈਨ ਕਰੋ ਤਾਂ ਜੋ ਮਰੀ ਹੋਈ ਸਾਈਨ ਹੋਸਟ ਤੁਹਾਨੂੰ ਅੱਧੀ ਰਾਤ ਰੂਟ ਖੋਲ੍ਹਣ ਲਈ ਮਜਬੂਰ ਨਾ ਕਰੇ।

ਇਸਨੂੰ ਪੂਰਾ ਕਹਿਣ ਤੋਂ ਪਹਿਲਾਂ ਪੰਜ ਗੱਲਾਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ: ਰੂਟ ਕੁੰਜੀ ਨੈੱਟਵਰਕ ਵਾਲੇ ਹੋਸਟ ’ਤੇ ਨਹੀਂ ਹੈ, ਵਿਚਕਾਰਲੀ ਕੁੰਜੀ ਸਿਰਫ਼ ਸਾਈਨ ਹੋਸਟ ’ਤੇ ਰਹਿੰਦੀ ਹੈ, ਕਲਾਇੰਟ ਬੰਡਲ ਦੋਵੇਂ CA ਸਰਟੀਫਿਕੇਟ ਰੱਖਦਾ ਹੈ, CRL ਵਿੱਚ ਭਵਿੱਖ ਦਾ ਅਗਲਾ ਅੱਪਡੇਟ ਹੈ, ਅਤੇ ਚੇਨ ਦੀ ਹਰ ਮਿਆਦ ਲਈ ਕਿਸੇ ਕੋਲ ਕੈਲੰਡਰ ਐਂਟਰੀ ਹੈ। ਜੇ ਇੱਕ ਵੀ ਨਾ ਹੋਵੇ, ਤਾਂ ਔਫਲਾਈਨ ਦਿਖਣ ਵਾਲਾ ਸੈੱਟਅੱਪ ਸਿਰਫ਼ ਅਣ-ਦਸਤਾਵੇਜ਼ੀ ਹੈ।