ਕ੍ਰਾਸ-ਸਾਈਨ ਕੀਤਾ CA: ਕੁੰਜੀ ਮੇਲ ਖਾਂਦੀ ਹੈ, AKI ਬਾਈਂਡਿੰਗ ਨਹੀਂ

ਦੋ CA ਪ੍ਰਮਾਣ ਪੱਤਰਾਂ ਕੋਲ ਇੱਕੋ ਜਨਤਕ ਕੁੰਜੀ ਅਤੇ ਇੱਕੋ subject ਹੋ ਸਕਦਾ ਹੈ ਅਤੇ ਫਿਰ ਵੀ ਉਹ ਬਦਲਣਯੋਗ ਨਹੀਂ ਹੁੰਦੇ। ਇੱਕ ਸਵੈ-ਸਾਈਨ ਕੀਤਾ ਹੈ, ਦੂਜਾ ਪੁਰਾਣੀ ਰੂਟ ਵੱਲੋਂ ਕ੍ਰਾਸ-ਸਾਈਨ ਕੀਤਾ ਹੈ, ਅਤੇ ਉਹਨਾਂ ਦੇ ਜਾਰੀਕਰਤਾ ਨਾਮ, ਕ੍ਰਮ ਸੰਖਿਆਵਾਂ ਅਤੇ ਸਾਈਨ ਵੱਖਰੇ ਹਨ। ਲੀਫ ਆਪਣੇ Authority Key Identifier ਰਾਹੀਂ ਖਾਸ ਤੌਰ 'ਤੇ ਇਹਨਾਂ ਵਿੱਚੋਂ ਇੱਕ ਨਾਲ ਬੱਝ ਸਕਦੀ ਹੈ। ਉਹ ਬਾਈਂਡਿੰਗ ਉਦੋਂ ਤੱਕ ਅਦਿੱਖ ਰਹਿੰਦੀ ਹੈ ਜਦੋਂ ਤੱਕ ਕੋਈ ਕਲਾਇੰਟ ਗਲਤ ਚੇਨ ਨਹੀਂ ਚੁਣਦਾ ਅਤੇ handshake ਕਿਸੇ ਸਪਸ਼ਟ ਕਾਰਨ ਤੋਂ ਬਿਨਾਂ ਫੇਲ ਨਹੀਂ ਹੁੰਦਾ।

ਇਹ ਪੰਜ ਜਾਂਚਾਂ ਕ੍ਰਮ ਵਿੱਚ ਕਰੋ: ਹਰ ਇੱਕ ਵੱਖਰੀ ਅਸਫਲਤਾ ਨੂੰ ਰੱਦ ਕਰਦੀ ਹੈ।

ਜਾਂਚ 1: ਟੈਂਪਲੇਟ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਦੋਵੇਂ ਚੇਨਾਂ ਖਿੱਚੋ

ਮਾਰਗ ਲਿਖ ਲਵੋ। ਪੁਰਾਣੀ ਆਬਾਦੀ ਪੁਰਾਣੀ ਰੂਟ A 'ਤੇ ਭਰੋਸਾ ਕਰਦੀ ਹੈ, ਜਿਸ ਨੇ CA B ਜਾਰੀ ਕੀਤਾ, ਜਿਸ ਨੇ ਸਰਵਰ ਦੀ ਲੀਫ ਜਾਰੀ ਕੀਤੀ। ਨਵੀਂ ਆਬਾਦੀ ਸਿੱਧਾ ਸਵੈ-ਸਾਈਨ ਕੀਤੇ CA B 'ਤੇ ਭਰੋਸਾ ਕਰਦੀ ਹੈ। ਦੋਵੇਂ B ਪ੍ਰਮਾਣ ਪੱਤਰ ਇੱਕੋ ਕੁੰਜੀ ਅਤੇ subject ਰੱਖਦੇ ਹਨ, ਅਤੇ ਇਸੇ ਕਰਕੇ subject ਲਾਈਨ ਪੜ੍ਹਨ ਵਾਲਾ ਵਿਅਕਤੀ ਇੱਕ CA ਦੇਖਦਾ ਹੈ ਜਿੱਥੇ ਕਲਾਇੰਟ ਦੋ ਦੇਖਦਾ ਹੈ।

ਕ੍ਰਾਸ-ਸਾਈਨ ਕੀਤੀ ਨਕਲ ਵੀ ਅਸਲੀ CA ਪ੍ਰਮਾਣ ਪੱਤਰ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ, ਜਿਸ ਵਿੱਚ basic constraints ਅਤੇ key usage ਸਾਈਨ ਕਰਨ ਦੀ ਆਗਿਆ ਦੇਣ।

ਜਾਂਚ 2: ਸਿਰਫ਼ ਕੁੰਜੀ ਨਹੀਂ, AKI ਫੀਲਡਾਂ ਦੀ ਤੁਲਨਾ ਕਰੋ

ਲੀਫ ਦਾ ਜਾਰੀਕਰਤਾ ਨਾਮ B ਦੇ subject ਨਾਲ ਮੇਲ ਖਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਉਹ ਹਿੱਸਾ ਆਮ ਤੌਰ 'ਤੇ ਟਿਕਦਾ ਹੈ। ਦੋ ਨਕਲਾਂ ਜਿੱਥੇ ਵੱਖ ਹੁੰਦੀਆਂ ਹਨ ਉਹ Authority Key Identifier ਹੈ, ਕਿਉਂਕਿ ਇਹ ਕੁੰਜੀ ਪਛਾਣਕਰਤਾ, ਜਾਰੀਕਰਤਾ ਪ੍ਰਮਾਣ ਪੱਤਰ ਅਤੇ ਕ੍ਰਮ ਸੰਖਿਆ ਰੱਖ ਸਕਦਾ ਹੈ। ਕੁੰਜੀ ਪਛਾਣਕਰਤਾ ਦੋਵੇਂ ਨਕਲਾਂ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ, ਕਿਉਂਕਿ ਕੁੰਜੀ ਇੱਕੋ ਹੈ। ਜਾਰੀਕਰਤਾ ਅਤੇ ਕ੍ਰਮ ਸੰਖਿਆ ਫੀਲਡ ਠੀਕ ਇੱਕ ਨਾਲ ਮੇਲ ਖਾਂਦੇ ਹਨ, ਇਸ ਲਈ ਸਵੈ-ਸਾਈਨ ਨਕਲ ਵਿਰੁੱਧ ਬਣੀ ਚੇਨ ਕ੍ਰਾਸ-ਸਾਈਨ ਨਕਲ ਵਿਰੁੱਧ ਫੇਲ ਹੋ ਸਕਦੀ ਹੈ।

ਅੰਦਾਜ਼ਾ ਲਾਉਣ ਦੀ ਥਾਂ ਲੀਫ ਦੀ ਜਾਂਚ ਕਰੋ: openssl x509 -in server.pem -noout -ext authorityKeyIdentifier।

ਫਿਰ ਦੋਵੇਂ ਉਮੀਦਵਾਰਾਂ ਦੀ openssl x509 -in b-cross.pem -noout -text | grep -A2 "Authority Key Identifier" ਨਾਲ ਤੁਲਨਾ ਕਰੋ, ਅਤੇ ਉਹੀ ਹੁਕਮ ਸਵੈ-ਸਾਈਨ ਨਕਲ ਵਿਰੁੱਧ ਚਲਾਓ।

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

ਜਾਂਚ 3: ਜਾਰੀ ਨੀਤੀ ਬਦਲੋ, ਸਾਈਨ ਕੀਤੇ ਬਾਈਟ ਕਦੇ ਨਹੀਂ

ਐਕਸਟੈਂਸ਼ਨ ਸਾਈਨ ਦੇ ਅੰਦਰ ਰਹਿੰਦੇ ਹਨ। ਮੌਜੂਦਾ ਲੀਫ 'ਤੇ ਇੱਕ ਜੋੜਨਾ, ਹਟਾਉਣਾ ਜਾਂ ਸੰਪਾਦਿਤ ਕਰਨਾ ਮੁਰੰਮਤ ਨਹੀਂ, ਇਹ ਵੱਖਰਾ ਪ੍ਰਮਾਣ ਪੱਤਰ ਹੈ, ਅਤੇ ਇਸ ਨੂੰ ਮੁੜ ਜਾਰੀ ਕਰਨਾ ਪੈਂਦਾ ਹੈ। ਤਬਦੀਲੀ ਜਾਰੀ ਨੀਤੀ ਵਿੱਚ ਆਉਂਦੀ ਹੈ: authorityKeyIdentifier = keyid,issuer:always ਨਵੀਆਂ ਲੀਫਾਂ ਨੂੰ ਪ੍ਰਮਾਣ-ਪੱਤਰ-ਖਾਸ ਬਾਈਂਡਿੰਗ ਰੱਖਣ ਦਿੰਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਇਕੱਲਾ keyid ਜਾਣ-ਬੁੱਝ ਕੇ ਕੀਤੇ ਕ੍ਰਾਸ-ਸਾਈਨਿੰਗ ਤਬਦੀਲੀ ਲਈ ਢੁੱਕਵਾਂ ਢਿੱਲਾ ਰੂਪ ਰੱਖਦਾ ਹੈ। ਅਗਲੀ ਬੈਚ ਸਾਈਨ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਤੈਅ ਕਰੋ ਕਿ ਤੁਹਾਡੀ PKI ਕੀ ਚਾਹੁੰਦੀ ਹੈ।

ਸਾਂਝਾ ਟੈਂਪਲੇਟ ਸੰਪਾਦਿਤ ਕਰਨ ਨਾਲ ਤੁਹਾਡੇ ਸਾਮ੍ਹਣੇ ਦਾ ਸਰਵਰ ਹੀ ਨਹੀਂ, ਹਰ ਭਵਿੱਖੀ ਪ੍ਰਮਾਣ ਪੱਤਰ ਵੀ ਬਦਲਦਾ ਹੈ।

ਜਾਂਚ 4: ਹਰ ਭਰੋਸਾ ਆਬਾਦੀ ਨੂੰ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਪ੍ਰਮਾਣਿਤ ਕਰੋ

ਪੁਰਾਣੇ ਮਾਰਗ ਅਤੇ ਨਵੇਂ ਮਾਰਗ ਨੂੰ ਵੱਖਰੇ ਰਨ ਵਜੋਂ ਪਰਖੋ। openssl verify -purpose sslserver -verify_hostname vpn.example -CAfile old-root.pem -untrusted b-cross-signed.pem server.pem ਕ੍ਰਾਸ-ਸਾਈਨ ਮਾਰਗ ਦਾ ਅਭਿਆਸ ਕਰਦਾ ਹੈ, ਅਤੇ ਨਵੀਂ ਰੂਟ ਅਤੇ untrusted ਫਾਈਲ ਤੋਂ ਬਿਨਾਂ ਉਹੀ ਹੁਕਮ ਸਵੈ-ਸਾਈਨ ਮਾਰਗ ਦਾ ਅਭਿਆਸ ਕਰਦਾ ਹੈ। ਦੋਵੇਂ ਰੂਟ ਇੱਕ ਬੰਡਲ ਵਿੱਚ ਮਿਲਾਉਣ ਨਾਲ ਲੁਕ ਜਾਂਦਾ ਹੈ ਕਿ ਕਿਹੜੀ ਚੇਨ ਚੁਣੀ ਗਈ। ਫਿਰ ਅਸਲੀ ਕਲਾਇੰਟਾਂ ਨਾਲ ਦੁਹਰਾਓ, ਕਿਉਂਕਿ VPN ਬੈਕਐਂਡ ਚੇਨ ਨੂੰ ਤਰਜੀਹ ਦੇ ਸਕਦਾ ਹੈ ਜਾਂ ਪ੍ਰਮਾਣ ਪੱਤਰ ਪਿੰਨ ਕਰ ਸਕਦਾ ਹੈ ਅਜਿਹੇ ਤਰੀਕਿਆਂ ਨਾਲ ਜੋ openssl ਨਹੀਂ ਕਰਦਾ।

ਵਿਚਕਾਰਲਾ ਪ੍ਰਮਾਣ ਪੱਤਰ ਉਸ ਸੇਵਾ ਸੰਰਚਨਾ ਰਾਹੀਂ ਦਿਓ ਜੋ ਕਲਾਇੰਟ ਅਸਲ ਵਿੱਚ ਪੜ੍ਹਦਾ ਹੈ, ਵਿਕੀ ਪੰਨੇ ਰਾਹੀਂ ਨਹੀਂ।

ਜਾਂਚ 5: ਪੁਰਾਣੇ ਮਾਰਗ ਨੂੰ ਰਿਟਾਇਰਮੈਂਟ ਘੜੀ 'ਤੇ ਰੱਖੋ

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

ਜੇ ਹਰ ਕਲਾਇੰਟ ਲੀਫ ਹਿਲਣ ਤੋਂ ਪਹਿਲਾਂ ਨਵੀਂ ਰੂਟ ਲੈ ਸਕਦਾ ਹੈ, ਤਾਂ ਸਾਧਾਰਨ ਦੋਹਰਾ-ਭਰੋਸਾ ਰੋਲਆਉਟ ਕ੍ਰਾਸ-ਸਾਈਨਿੰਗ ਤੋਂ ਸੌਖਾ ਹੈ, ਅਤੇ ਰਿਟਾਇਰ ਕਰਨ ਲਈ ਇੱਕ ਚੀਜ਼ ਘੱਟ ਛੱਡਦਾ ਹੈ।