인증 기관 루트 인증서 만료 및 갱신

2004 년에는 Linux에서 OpenSSL을 사용하고 OpenVPN과 함께 제공되는 간단한 관리 스크립트를 사용하여 소규모 인증 기관을 설정했습니다. 당시에 찾은 안내서에 따라 루트 CA 인증서의 유효 기간을 10 년으로 설정했습니다. 그 이후로 OpenVPN 터널, 웹 사이트 및 전자 메일 서버에 대한 많은 인증서에 서명했으며 모두 유효 기간이 10 년입니다 (이는 잘못되었지만 당시에는 더 잘 알지 못했습니다).

CA 설정에 대한 많은 가이드를 찾았지만 관리, 특히 루트 CA 인증서가 만료 될 때 수행해야 할 작업에 대한 정보는 거의 없었습니다. 이는 2014 년에 약간의 시간이 걸릴 것입니다. 질문 :

• 루트 CA 인증서가 만료 된 후 유효 기간이 연장 된 인증서가 만료 되 자마자 유효하지 않습니까 (CA 인증서의 유효 기간 동안 서명 되었기 때문에) 계속 유효합니까?
• 루트 CA 인증서를 갱신하고 만료 기간 동안 원활하게 전환하려면 어떤 작업이 필요합니까?
  • 다른 유효 기간으로 현재 루트 CA 인증서를 다시 서명하고 클라이언트 인증서가 클라이언트에 유효한 상태로 유지되도록 새로 서명 된 인증서를 클라이언트에 업로드 할 수 있습니까?
  • 아니면 모든 클라이언트 인증서를 새 루트 CA 인증서로 서명 된 새 인증서로 바꿔야합니까?
• 루트 CA 인증서는 언제 갱신해야합니까? 만료가 가까워 지거나 만료 전에 합리적인 시간이 있습니까?
• 루트 CA 인증서의 갱신이 주요 작업이되는 경우, 다음 갱신시보다 원활하게 전환하기 위해 (물론 유효 기간을 100 년으로 설정하지 않은 경우) 어떻게해야합니까?

일부 클라이언트에 대한 유일한 액세스는 현재 CA 인증서로 서명 된 인증서를 사용하는 OpenVPN 터널을 통해 이루어 지므로 상황이 약간 더 복잡해집니다. 따라서 모든 클라이언트 인증서를 교체해야하는 경우 복사해야합니다. 새 파일을 클라이언트에 보내고 터널을 다시 시작한 다음 내 손가락을 건너서 나중에 다시 나오기를 바랍니다.

루트 CA에 동일한 개인 키를 유지하면 모든 인증서가 새 루트에 대해 계속해서 유효성을 검사 할 수 있습니다. 당신에게 필요한 것은 새로운 루트를 신뢰하는 것입니다.

인증서 서명 관계는 개인 키의 서명을 기반으로합니다. 새로운 공개 인증서를 생성하는 동안 동일한 개인 키 (및 내재적으로 동일한 공개 키)를 유지하면서 새로운 유효 기간과 다른 새 속성이 필요에 따라 변경되면 신뢰 관계가 유지됩니다. CRL도 인증서와 같이 개인 키로 서명 된 것처럼 기존 인증서에서 새 인증서로 계속 이어질 수 있습니다.

자, 확인합시다!

루트 CA를 만듭니다.

openssl req -new -x509 -keyout root.key -out origroot.pem -days 3650 -nodes

하위 인증서를 생성하십시오.

openssl genrsa -out cert.key 1024
openssl req -new -key cert.key -out cert.csr

자녀 증명서에 서명하십시오 :

openssl x509 -req -in cert.csr -CA origroot.pem -CAkey root.key -create_serial -out cert.pem
rm cert.csr

모든 인증서가 설정되었습니다. 신뢰를 확인합시다 :

# openssl verify -CAfile origroot.pem -verbose cert.pem
cert.pem: OK

자 이제 10 년이 지났다고합시다. 동일한 루트 개인 키에서 새 공개 인증서를 생성 해 봅시다.

openssl req -new -key root.key -out newcsr.csr
openssl x509 -req -days 3650 -in newcsr.csr -signkey root.key -out newroot.pem
rm newcsr.csr

그리고 .. 작동 했습니까?

# openssl verify -CAfile newroot.pem -verbose cert.pem
cert.pem: OK

근데 왜? 다른 파일 이지요?

# sha1sum newroot.pem
62577e00309e5eacf210d0538cd79c3cdc834020  newroot.pem
# sha1sum origroot.pem
c1d65a6cdfa6fc0e0a800be5edd3ab3b603e1899  origroot.pem

그렇다고해서 새로운 공개 키가 인증서의 서명과 암호 적으로 일치하지는 않습니다. 다른 일련 번호, 동일한 계수 :

# openssl x509 -noout -text -in origroot.pem
        Serial Number:
            c0:67:16:c0:8a:6b:59:1d
...
            RSA Public Key: (1024 bit)
                Modulus (1024 bit):
                    00:bd:56:b5:26:06:c1:f6:4c:f4:7c:14:2c:0d:dd:
                    3c:eb:8f:0a:c0:9d:d8:b4:8c:b5:d9:c7:87:4e:25:
                    8f:7c:92:4d:8f:b3:cc:e9:56:8d:db:f7:fd:d3:57:
                    1f:17:13:25:e7:3f:79:68:9f:b5:20:c9:ef:2f:3d:
                    4b:8d:23:fe:52:98:15:53:3a:91:e1:14:05:a7:7a:
                    9b:20:a9:b2:98:6e:67:36:04:dd:a6:cb:6c:3e:23:
                    6b:73:5b:f1:dd:9e:70:2b:f7:6e:bd:dc:d1:39:98:
                    1f:84:2a:ca:6c:ad:99:8a:fa:05:41:68:f8:e4:10:
                    d7:a3:66:0a:45:bd:0e:cd:9d
# openssl x509 -noout -text -in newroot.pem
        Serial Number:
            9a:a4:7b:e9:2b:0e:2c:32
...
            RSA Public Key: (1024 bit)
                Modulus (1024 bit):
                    00:bd:56:b5:26:06:c1:f6:4c:f4:7c:14:2c:0d:dd:
                    3c:eb:8f:0a:c0:9d:d8:b4:8c:b5:d9:c7:87:4e:25:
                    8f:7c:92:4d:8f:b3:cc:e9:56:8d:db:f7:fd:d3:57:
                    1f:17:13:25:e7:3f:79:68:9f:b5:20:c9:ef:2f:3d:
                    4b:8d:23:fe:52:98:15:53:3a:91:e1:14:05:a7:7a:
                    9b:20:a9:b2:98:6e:67:36:04:dd:a6:cb:6c:3e:23:
                    6b:73:5b:f1:dd:9e:70:2b:f7:6e:bd:dc:d1:39:98:
                    1f:84:2a:ca:6c:ad:99:8a:fa:05:41:68:f8:e4:10:
                    d7:a3:66:0a:45:bd:0e:cd:9d

실제 인증서 유효성 검사에서 작동하는지 확인하기 위해 조금 더 나아가 보겠습니다.

아파치 인스턴스를 시작하고 이동시켜 보자 (데비안 파일 구조, 필요에 따라 조정) :

# cp cert.pem /etc/ssl/certs/
# cp origroot.pem /etc/ssl/certs/
# cp newroot.pem /etc/ssl/certs/
# cp cert.key /etc/ssl/private/

우리는이 지시어를 VirtualHost443 에서 청취 하도록 설정할 것입니다 . newroot.pem루트 인증서 cert.pem는 생성되어 서명 될 때조차 존재하지 않았 음을 기억하십시오 .

SSLEngine on
SSLCertificateFile /etc/ssl/certs/cert.pem
SSLCertificateKeyFile /etc/ssl/private/cert.key
SSLCertificateChainFile /etc/ssl/certs/newroot.pem

openssl이 어떻게 보이는지 확인하십시오.

# openssl s_client -showcerts -CAfile newroot.pem -connect localhost:443

Certificate chain
 0 s:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=server.lan
   i:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
 1 s:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
   i:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
-----BEGIN CERTIFICATE-----
MIICHzCCAYgCCQCapHvpKw4sMjANBgkqhkiG9w0BAQUFADBUMQswCQYDVQQGEwJB
...
-----END CERTIFICATE-----
(this should match the actual contents of newroot.pem)
...
Verify return code: 0 (ok)

좋아, 그리고 MS의 암호화 API를 사용하는 브라우저는 어떻습니까? 먼저 루트를 신뢰해야합니다. 그러면 새로운 루트의 일련 번호로 모든 것이 좋습니다.

그리고 우리는 여전히 오래된 뿌리를 가지고 일해야합니다. Apache 설정을 다음과 같이 전환하십시오.

SSLEngine on
SSLCertificateFile /etc/ssl/certs/cert.pem
SSLCertificateKeyFile /etc/ssl/private/cert.key
SSLCertificateChainFile /etc/ssl/certs/origroot.pem

Apache를 완전히 다시 시작하면 다시로드해도 인증서가 올바르게 전환되지 않습니다.

# openssl s_client -showcerts -CAfile origroot.pem -connect localhost:443

Certificate chain
 0 s:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=server.lan
   i:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
 1 s:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
   i:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
-----BEGIN CERTIFICATE-----
MIIC3jCCAkegAwIBAgIJAMBnFsCKa1kdMA0GCSqGSIb3DQEBBQUAMFQxCzAJBgNV
...
-----END CERTIFICATE-----
(this should match the actual contents of origroot.pem)
...
Verify return code: 0 (ok)

그리고 MS crypto API 브라우저를 사용하여 Apache는 이전 루트를 제시하지만 새 루트는 여전히 컴퓨터의 신뢰할 수있는 루트 저장소에 있습니다. Apache는 다른 체인 (이전 루트)을 제시하지만 신뢰할 수있는 (신규) 루트에 대해 자동으로 그것을 찾고 인증서의 유효성을 검사합니다. 신뢰할 수있는 루트에서 새 루트를 제거하고 원래 루트 인증서를 추가하면 모든 것이 잘됩니다.

그게 다야! 갱신 할 때 동일한 개인 키를 유지하고 신뢰할 수있는 새로운 루트를 바꾸면 거의 모두 작동합니다 . 행운을 빕니다!

원래 CA 키의 갱신 된 인증서에서 CA 확장이 누락 될 수 있음을 알았습니다. 이 날 (그것이 만들어 더 적절했다 ./renewedselfsignedca.conf V3의 CA 확장이 정의되고, ca.key 와 ca.crt는 CA 키 및 인증서 원본 것으로 가정) :

openssl x509 -x509toreq -in ca.crt -signkey ca.key -out renewedselfsignedca.csr
echo -e "[ v3_ca ]\nbasicConstraints= CA:TRUE\nsubjectKeyIdentifier= hash\nauthorityKeyIdentifier= keyid:always,issuer:always\n" > renewedselfsignedca.conf
openssl x509 -req -days 1095 -in renewedselfsignedca.csr -signkey ca.key -out renewedselfsignedca.crt -extfile ./renewedselfsignedca.conf -extensions v3_ca

유효한 루트 기간을 연장하는 기본 모드 (공개 X.509 및 연관된 개인 키가 필요함) :

공개 X.509 및 개인 키에서 CSR을 생성하십시오.

openssl x509 -x509toreq -in XXX.crt -signkey XXX.key -out XXX.csr

개인 키를 사용하여 CSR에 다시 서명하십시오.

openssl x509 -in XXX.csr -out XXX.crt -signkey XXX.key -req -days 365

@Bianconiglio plus -set_serial이 나를 위해 일했습니다. 내 서버는 인트라넷이므로 부작용이 무엇인지 걱정할 필요가 없으며 이제 "적절한"솔루션으로 작업 할 시간이 있습니다.

다음 구성 가능한 스크립트를 사용했습니다. 변수 CACRT, CAKEY 및 NEWCA 만 설정하십시오.

# WF 2017-06-30
# https://serverfault.com/a/501513/162693
CACRT=SnakeOilCA.crt
CAKEY=SnakeOilCA.key
NEWCA=SnakeOilCA2017
serial=`openssl x509 -in $CACRT -serial -noout | cut -f2 -d=`
echo $serial
openssl x509 -x509toreq -in $CACRT -signkey $CAKEY -out $NEWCA.csr
echo -e "[ v3_ca ]\nbasicConstraints= CA:TRUE\nsubjectKeyIdentifier= hash\nauthorityKeyIdentifier= keyid:always,issuer:always\n" > $NEWCA.conf
openssl x509 -req -days 3650 -in $NEWCA.csr -set_serial 0x$serial -signkey $CAKEY -out $NEWCA.crt -extfile ./$NEWCA.conf -extensions v3_ca
openssl x509 -in $NEWCA.crt -enddate -serial -noout

루트 인증서가 만료되면 서명 한 인증서도 만료됩니다. 새 루트 인증서를 생성하고 새 인증서를 서명해야합니다. 몇 년마다 프로세스를 반복하지 않으려면 유일한 유일한 옵션은 루트 인증서의 유효 날짜를 10 년 또는 20 년과 같이 연장하는 것입니다.

루트 인증서를 "갱신"할 수 없습니다. 새로운 것을 생성하기 만하면됩니다.

오래된 것이 만료되기 최소 1 년 또는 2 년 전에 새 루트를 생성하여 문제가 발생했을 때 타임 월에 대항하지 않고 전환 할 시간을 가지십시오. 이렇게하면 새 인증서로 치아 문제가 해결 될 때까지 항상 기존 인증서로 일시적으로 다시 전환 할 수 있습니다.

VPN 터널까지는 실험 할 몇 개의 테스트 베드 서버를 설정하여 클라이언트 컴퓨터로 작업하기 전에 수행해야 할 작업을 정확하게 이해할 수 있습니다.

우리는 같은 문제를 겪었고 데비안 서버가 최신이 아니었고 openSSL에 다음과 같은 문제가 있었기 때문에 우리의 경우였습니다.

https://ko.wikipedia.org/wiki/Year_2038_problem

데비안 6에서 사용 가능한 마지막 OpenSSL 버전은이 문제를 일으 킵니다. 23.01.2018 이후에 생성 된 모든 인증서는 Vality : for 1901 year!

해결책은 OpenSSL을 업데이트하는 것입니다. 클라이언트에 대한 구성 파일 (인증서 포함)을 다시 작성할 수 있습니다.