자체 인증 기관이 된 후 클라이언트측 인증서를 생성할 수 없습니다.

자체 인증 기관이 된 후 클라이언트측 인증서를 생성할 수 없습니다.

나만의 인증 기관이 되었습니다다음 튜토리얼을 실행한 후:https://jamielinux.com/docs/openssl-certificate-authority/

루트 쌍을 만들고, 중간 쌍을 만들고, 다음과 같이 squid에 설치한 서버 인증서에 서명했습니다.

http_port 3129 ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=4MB cert=/etc/squid3/certs/gatesentry.csr.cert.pem key=/etc/squid3/key/gatesentry.key.pem

~에squid3.conf

오징어는 이것으로 잘 시작됩니다. 실제로 작동하는지 여부는 아직 확실하지 않습니다.

프록시를 통해 인터넷에 액세스할 브라우저에 설치하기 위해 클라이언트 측 인증서를 생성하려고 하면 오류가 발생합니다.

기반으로 생성하고 있어요."인증서 만들기"라는 "서버 및 클라이언트 인증서 서명" 섹션

인증을 위해 클라이언트 인증서를 만들려면 'usr_crt' 확장을 사용해야 하므로 다음을 실행한다고 명시되어 있습니다.

cd /root/ca
openssl ca -config intermediate/openssl.conf \
      -extensions usr_cert -days 375 -notext -md sha256 \
      -in intermediate/csr/gatesentry.csr.pem \
      -out intermediate/certs/client.cert.pem
Using configuration from intermediate/openssl.conf
Enter pass phrase for /root/ca/intermediate/private/intermediate.key.pem:
Check that the request matches the signature
Signature ok
Certificate Details:
        Serial Number: 4097 (0x1001)
        Validity
            Not Before: Jun 22 10:36:44 2016 GMT
            Not After : Jul  2 10:36:44 2017 GMT
        Subject:
            countryName               = US
            stateOrProvinceName       = Pennsylvania
            localityName              = locality
            organizationName          = Parents
            organizationalUnitName    = Security
            commonName                = gatesentry.domain.lan
            emailAddress              = [email protected]
        X509v3 extensions:
            X509v3 Basic Constraints: 
                CA:FALSE
            Netscape Cert Type: 
                SSL Client, S/MIME
            Netscape Comment: 
                OpenSSL Generated Client Certificate
            X509v3 Subject Key Identifier: 
                XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX
            X509v3 Authority Key Identifier: 
                keyid:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX

            X509v3 Key Usage: critical
                Digital Signature, Non Repudiation, Key Encipherment
            X509v3 Extended Key Usage: 
                TLS Web Client Authentication, E-mail Protection
Certificate is to be certified until Jul  2 10:36:44 2017 GMT (375 days)
Sign the certificate? [y/n]: y
failed to update database
TXT_DB error number 2

루트로 명령을 실행할 때(물론 다른 컴퓨터에서) TXT_DB 오류 번호 2 메시지가 나타나는 이유를 이해할 수 없습니다.

튜토리얼에 따르면 이 과정에서 일반 이름을 변경할 수 있어야 합니다.

답변1

TXT_DB error number 2DB_ERROR_INDEX_CLASH를 의미합니다.

동일한 인덱스를 사용하여 OpenSSL CA 데이터베이스에 인증서를 두 번 제출하려고 했습니다.

그 원인은 일반적으로 동일한 일련 번호 또는 동일한 일반 이름을 포함하는 데이터베이스에 인증서를 제출하기 때문입니다. 후자의 경우 파일 unique_subject의 옵션을 확인하세요. intermediate/openssl.conf이에 대한 내용은 에서 읽을 수 있습니다 man ca.

클라이언트 인증서의 일반 이름은 무엇이든 될 수 있습니다(예: 이름).

일반 이름은 파일에 지정됩니다 intermediate/openssl.conf. 값을 묻는 메시지를 표시하거나 구성 파일에서 값을 읽도록 구성할 수 있습니다. 이는 prompt에서 읽을 수 있는 옵션 에 의해 제어됩니다 man req.

답변2

튜토리얼에 따르면 이 과정에서 일반 이름을 변경할 수 있어야 합니다.

해당 튜토리얼에서는 AND를 사용하여 새 키를 생성하고 openssl genrsa를 사용하여 openssl req -newCSR에서 인증서를 생성하도록 지시합니다 openssl ca. (너무 많은 사람들이 'CSR에 서명'하여 인증서가 생성된다고 잘못 말하고 있지만 CA는 CSR에 서명하지 않습니다. CA는 인증서에 서명합니다.부분적으로 기반CSR이지만 CSR과는 다릅니다. /호언장담)

새 CSR을 생성하는 경우위에 있는 CA 인증서와 달라야 하는 일반 이름을 포함하되 이에 국한되지 않는 주체 이름을 지정합니다.~해야 한다혼동을 피하기 위해 다른 EE 인증서와 다릅니다.

openssl ca실제로 발급된 인증서의 주체 이름(개별 공통 이름이 아닌 전체 이름)을 재정의할 수 있지만 이렇게 하면 동일한 키에 대해 다른 이름을 가진 인증서가 생성되어 기껏해야 불필요하게 혼란스럽고 일반적으로 덜 안전합니다(비록 그렇게 하지 않더라도). 그 부분은 남들이 신경쓰니까 쉽지 않더라구요).

usr-crt 섹션에서 확장 프로그램을 로드하는 중 오류가 발생했습니다
. 값 없음 ... name=email_in_dn
업스트림 기본 파일에서 오는 것일 수 있습니까?

직접적으로는 아닙니다. openssl ca -config xxxxxx 및 xxx만 구성 파일로 사용합니다. 파일이 업스트림에서 파생된 경우 원하는 섹션 이름은 usr_cert분명히 발견한 것과 같지만 usr_cert가 기본값이므로 지정할 필요가 없습니다. email_in_dn에 대한 오류 메시지는 오류 스택에 남아 있으며 유일한 실제 오류는 usr-crt; -noemailDN어쨌든 원할 수도 있지만 일단 수정하면 필요하지 않습니다.

이것이 subjectNameAlt와 관련이 있습니까?

당신이 의미한다고 가정하면 unique_subject, 아니오. subjectAltName(아님 subjectNameAlt) SAN이라고도 하는 것은 주제에 대한 대체 이름을 지정하지만 SAN이 아닌 unique_subject기본 필드에만 관련되는 공통 확장입니다.Subject

프록시를 통해 인터넷에 액세스할 브라우저에 설치할 클라이언트 측 인증서

분명히 말하면 이와 같은 클라이언트 인증서는 자신을 인증하는 데에만 유용합니다.프록시에. 클라이언트/브라우저의 인증서를 사용하여 HTTPS MitM을 통해 인터넷의 무언가에 인증할 수 없으며, 인터넷에 있는 다른 사람의 시스템에 인증하기 위해 직접 발급한 클라이언트 인증서를 사용할 수 없습니다.

관련 정보