자체 서명 된 루트 CA가 서명 한 인증서를 무효화하지 않고 재발급

회사 내부의 일부 내부 서비스에 대해 자체 서명 된 루트 인증 기관을 만들었습니다. 그런 다음이 CA에 서명 한 해당 서비스에 대한 인증서를 작성했습니다.

이제이 CA에서 발급 된 기존 서버 인증서를 무효화하지 않고 루트 CA에 x509 확장 (CRL 배포 지점)을 추가하려고합니다. 이게 가능해?

내가 이해하는 것처럼 해당 개인 키에 대한 액세스가 필요 하고 인증서 ID에 대한 "전체 권한"에 충분하기 때문에 내 직감은 "예" 입니다. 즉, 인증서가 생성 될 때 공개 키와 함께 일종의 nonce가 인증서에 통합되지 않은 경우입니다.

나는 여전히 SSL 인증서 관리에 익숙하지 않지만 표준 신뢰 체인의 기본 사항을 이해합니다. 다른 PKI 암호화의 기본 사용에 익숙합니다. SSH 키를 관리하고 서명 및 암호화에 GPG를 사용합니다. 나는 컴퓨터 과학을 공부했지만 암호 해독에있어 독학입니다.

나는 원래의 IIRC에 대한 CSR을 만들지 않았다 (나는 그것이 직접적인 결과라고 생각한다 openssl req -new -x509). 물론 원래 CA의 개인 키를 가지고 있으며이를 사용하여 원래 인증서를 인증서 서명 요청으로 "역방향으로"바꿀 수있었습니다. openssl x509 -x509toreq -in MyCA.pem -out MyCA.csr -signkey private/MyCA.key

나는 이것이 위에서 언급 한 nonce를 효과적으로 "추출"하고 crlDistributionPoints필드 를 사용하여 인증서를 다시 만들 수 있기를 원했기 때문에 원래 CA로 서명 된 모든 인증서는 여전히이 새로운 CA에 대해 유효성을 검사하지만 예외는 예외입니다. 클라이언트는 필드에 지정된 HTTP URL에서 (현재 비어있는) CRL 파일을 검색합니다.

그래서 확장 설정 파일을 만들었습니다 ext.conf:

[ cert_ext ] 
subjectKeyIdentifier=hash
crlDistributionPoints=URI:http://security.mycompany.co.za/root.crl

그리고 CSR에서 루트 CA의 새 버전을 생성했습니다.

openssl x509 -extfile ./ext.conf -extensions cert_ext -req -signkey private/MyCA.key -in MyCA.csr -out MyNewCA.pem

이제 인증서를 볼 때 openssl x509 -text -in MyNewCA.pem | less

CRL 확장 부분을 볼 수 있습니다.

X509v3 extensions:
    X509v3 Subject Key Identifier: 
        82:D0:01:03:49:FF:30:16:FA:DC:0A:1E:C1:8C:3D:66:A1:78:FF:F8
    X509v3 CRL Distribution Points: 

        Full Name:
          URI:http://security.mycompany.co.za/root.crl`

그러나 아아! 이전에 서명 한 인증서가이 인증서에 대해 더 이상 유효하지 않습니다.

openssl verify -verbose -CAfile MyCA.pem git.pem 
git.pem: OK

openssl verify -verbose -CAfile MyNewCA.pem git.pem 
git.pem: <redacted DN>
error 20 at 0 depth lookup:unable to get local issuer certificate

주로 인증서의 작동 방식과 이유에 대한 더 많은 통찰력을 찾고 있습니다. 그러나 나는이 문제로 이어지는 문제에 대한 해결책을 환영합니다. 그래서 여기에도 배경 정보가 있습니다.

나는이 혼란에있어 어떻게 내 CA는 Windows에서 인증서 GUI를 설치 → 탐색기 RMB를 통해 설치하거나되면 HTTPS 내부 서비스에 큰 일을 /usr/local/share/ca-certificates다음 update-ca-certificates데비안과 우분투. 그러나 최근 예외가 발생했습니다. Windows의 Git, 특히 Windows 보안 채널을 SSL 백엔드로 사용하도록 설치된 경우. 기본적으로 SSL 인증서에 CRL 필드가 있어야한다고 주장합니다.

따라서 계속 실행되는 오류 메시지가 Microsoft와 관련이 있기 때문에 실제로 Windows 보안 채널 문제인 것 같습니다. fatal: unable to access 'https://angery@git.mycompany.co.za/gitblit/r/secret_project.git/': schannel: next InitializeSecurityContext failed: Unknown error (0x80092012) - The revocation function was unable to check revocation for the certificate.

OpenSSL을 사용하여 Git을 설치하고 git.http.sslcainfo가 가리키는 파일에 내 CA를 수동으로 연결하면 작동하지만 사용자 가이 프로세스가 더 많은 노력을 기울이는 것보다 SSL 신원 확인에 신경 쓰지 않을까 두려워합니다. "easy"Windows 인증서 설치 프로그램 GUI를 클릭하십시오.

인증서의 주체 이름 과 공개 키 가 일치하는 한 두 개의 인증서가 동일한 것으로 간주됩니다 .

따라서 키를 재사용하고 새 인증서의 주체 이름이 이전과 동일한 지 확인하기 만하면됩니다. 그런 다음 다른 필드 및 / 또는 확장을 변경할 수 있으며 결과 인증서는 동일하게 간주됩니다.

예를 들어, OpenSSL 구성 파일을 작성하십시오.

[ req ]

prompt             = no
string_mask        = default
distinguished_name = x509_distinguished_name
x509_extensions     = x509_ext

[ x509_distinguished_name ]

# Note that the following are in 'reverse order' to what you'd expect to see.
# Adjust for your setup:

countryName = za
organizationName = My Company
organizationalUnitName = Security
commonName = My Root CA

[ x509_ext ]

basicConstraints = critical,CA:true
keyUsage = critical, keyCertSign, cRLSign
subjectKeyIdentifier = hash
crlDistributionPoints = URI:http://security.mycompany.co.za/root.crl

예를 들어 rootca.cnf. 의 요소가 [req_distinguished_name]원래 루트 CA 인증서 의 요소와 동일한 지 확인하십시오 (이는 동일한 주체 이름 부분 임).

다음을 실행하십시오.

openssl req -new -x509 -key rootca.key -out MyNewCA.pem -config rootca.cnf

rootca.key원래 인증서에 사용 된 개인 키는 어디 입니까 (이는 동일한 공개 / 개인 키 부분입니다).

이것 MyNewCA.pem으로 다음을 확인할 수 있습니다.

$ openssl x509 -noout -text -in MyNewCA.pem

Certificate:
Data:
    Version: 3 (0x2)
    Serial Number: 17564687072266118846 (0xf3c24dd49d5166be)
Signature Algorithm: sha256WithRSAEncryption
    Issuer: C=za, O=My Company, OU=Security, CN=My Root CA
    Validity
        Not Before: Jul 15 05:05:54 2017 GMT
        Not After : Aug 14 05:05:54 2017 GMT
    Subject: C=za, O=My Company, OU=Security, CN=My Root CA
    Subject Public Key Info:
        Public Key Algorithm: rsaEncryption
            Public-Key: (2048 bit)
            Modulus:
                00:c8:3d:32:8a:56:31:f6:27:1a:ce:9e:b2:1d:fb:
                ce:9f:ce:5b:42:25:aa:fe:8b:f4:34:32:ac:b3:02:
                50:71:f8:c3:43:0c:c7:2c:9f:fe:48:1b:c6:c0:e7:
                d6:44:a9:e7:d7:a0:7e:58:f4:b6:38:61:7e:d0:af:
                0f:56:21:e7:49:7a:66:13:f5:7a:fe:3d:ab:65:f8:
                01:eb:52:a7:3b:ae:a0:cf:50:57:b9:e0:09:0b:1f:
                90:14:fb:18:56:1d:57:99:a9:76:a2:63:d1:c2:d3:
                a3:f4:3a:ff:91:0d:ee:8d:44:13:58:00:09:93:da:
                e8:6a:fd:64:5f:c3:42:8e:2a:49:6e:0d:73:b7:b9:
                d4:6c:c6:ce:30:c5:82:24:a5:00:37:17:a0:1d:f1:
                c9:e9:e3:18:48:22:4f:33:96:a7:3c:a9:31:f1:3f:
                14:40:6a:74:e8:78:82:45:04:d4:4b:56:0b:cd:be:
                48:8d:03:fb:39:70:0b:91:99:70:06:bd:5e:8b:f2:
                d1:f4:6f:fc:ce:e7:f8:3c:0a:20:ea:35:b8:5f:2f:
                ee:8d:ff:d3:93:85:6b:fb:71:db:1b:e6:e9:1d:a7:
                f8:e4:ae:f4:71:fe:35:a7:89:24:af:69:a4:34:3b:
                14:66:05:02:5e:2a:1d:ac:e0:d2:48:6c:13:4e:75:
                58:93
            Exponent: 65537 (0x10001)
    X509v3 extensions:
        X509v3 Basic Constraints: critical
            CA:TRUE
        X509v3 Key Usage: critical
            Certificate Sign, CRL Sign
        X509v3 Subject Key Identifier: 
            3B:45:93:3A:2A:BC:39:29:36:13:6C:BD:B6:B4:31:C7:E7:BB:32:73
        X509v3 CRL Distribution Points: 

            Full Name:
              URI:http://security.mycompany.co.za/root.crl

Signature Algorithm: sha256WithRSAEncryption
     4d:96:d4:03:4f:e3:7c:26:be:59:f8:23:87:60:f7:4c:d3:a1:
     1c:77:a1:14:e3:e7:da:c8:2a:a3:1b:06:2a:4d:55:1c:83:26:
     73:46:0d:8a:e4:b7:d1:1e:38:cc:78:90:00:01:b3:8e:f9:3c:
     62:be:04:09:90:4e:22:87:b1:aa:bd:f9:73:bd:a7:76:ad:d5:
     ae:2d:7a:1c:1e:1a:67:c8:57:4c:f9:6d:8b:62:d6:e5:ea:e0:
     40:5c:12:28:7e:ea:f0:0c:d6:cd:f4:1d:d5:56:09:ad:43:b4:
     eb:8c:68:ce:56:a2:a8:ae:a4:d5:35:bb:58:b8:ed:82:82:b5:
     ef:cb:e2:6d:76:61:ed:ee:a5:1f:68:95:07:ed:5b:f0:65:92:
     d2:dc:1d:c6:fa:7f:e0:c9:38:c2:c6:6f:03:38:e7:3a:b0:24:
     06:e0:bc:07:dd:e7:a0:dc:74:09:e5:37:7b:66:e1:6f:47:4c:
     71:ff:02:48:7f:d4:4f:ce:cb:91:e9:ee:cd:b6:f1:0a:03:19:
     3e:19:05:7d:8f:48:e7:f1:cc:07:37:3d:91:3c:6f:54:71:3c:
     a2:6c:55:c3:03:c1:7f:eb:9e:70:f1:8f:a1:fb:62:33:8b:86:
     2c:79:bc:76:e2:01:9a:68:df:af:40:a1:b2:9c:f6:a1:e1:6e:
     2a:dd:1a:d6

원본 대신이 새 인증서를 사용하십시오.

인증서의 유효 기간과 같은 다른 필드와 확장명을 변경할 수 있지만 basicConstraints = critical,CA:true루트 CA 인증서에 대한 제약 조건 (이외 ) 은 없어야합니다 .

추가 고려 사항이 있으면 대체 루트 CA 인증서 basicConstraint에 keyUsage확장자 가 없거나 확장명 이 없다는 사실만으로 문제가 될 수 있습니다 . 두 가지 확장을 ext.conf첫 번째에 추가하고 -x509toreq게시 한 방법을 사용하여 결과로 생성 된 새 루트 CA 인증서를 테스트 해 보는 것이 좋습니다.