☰

X.509 인증서는 Chrome에서 오류를 발생하지만 Firefox에서는 작동합니다.

tag-icon • tag-icon debian chrome
X.509 인증서는 Chrome에서 오류를 발생하지만 Firefox에서는 작동합니다.

RedHat 6.2 VM방금 Apache 2.2를 실행하는 사이트/가상 호스트에서 Multicert가 발급한 공개 X.509 인증서를 업데이트했습니다. 그렇게 부르자https://www.multicert.com. 사이트에 액세스하기 위해 Chrome을 사용하는 내 클라이언트 컴퓨터가 실행 중입니다 Debian 9.

놀랍게도 인증서는 Firefox Quantum 60.2.0esr(64비트) 및 Safari 모두에서 승인/녹색을 제공했지만 이제 Chrome 69.0.3497.92에서는 사이트가 안전하지 않다고 불평합니다(이전에 이전 인증서를 사용할 때는 괜찮았습니다). .

Apache 구성을 확인했는데 모든 것이 괜찮은 것 같습니다. 또한 X.509 인증서 체인과 루트를 세 번 검사했는데 모든 것이 괜찮은 것 같습니다.

유사하게 구성된 사이트에 대해 동시에 또 다른 공개 인증서가 발급되었지만 발급되었지만 Comodo발급되지 않았 Multicert으며 이 사이트에서는 Chrome이 인증서와 잘 작동했습니다. 이를 호출하겠습니다.https://www.digicert.com

이전 인증서로 되돌리면 크롬은 다시 작동하겠지만, 내일 해지되고 며칠 뒤에 만료될 수 있기 때문에 그냥 유지할 수는 없습니다.

Comodo 인증서가 있는 웹사이트에서 우리가 발견한 유일한 변경 사항은 Chrome에서 인증서를 클릭할 때 lock->Certificate-details"확장" 아래에 식별자가 있는 새 필드가 있다는 것입니다.OID.1.3.6.1.4.1.1.11129.2.4.2

영상

여기서 무슨 일이 일어나고 있는 걸까요?

답변1

OID가 주어지면 .1.3.6.1.4.1.1.11129.2.4.2관련 Let's Encrypt 기사를 찾았습니다.엔지니어링 심층 토론: 인증서의 SCT 인코딩

Let's Encrypt는 최근 인증서에 SCT를 포함하는 기능을 도입했습니다. 이 기능을 사용하면 브라우저에서 인증서가 인증서 투명성 로그에 제출되었는지 확인할 수 있습니다.

저는 이 주제에 대해 조사를 시작했고 결국 Google이 2018년 5월 1일부터 모든 유형의 X.509 인증서에 대해 Chrome에서 인증서 투명성을 시행하고 있다는 사실을 알게 되었습니다.

~에서Google Chrome의 인증서 투명성 시행

이 알림은 공통 CA 데이터베이스[1]에 알려진 모든 CA 운영자에게 전송되며 Chrome이 현재 또는 향후 실행될 수 있는 플랫폼(Mozilla NSS, Microsoft Windows, Apple iOS/macOS, Google ChromeOS 및 Android)에 적용됩니다. .

Chrome이 2018년 4월에 인증서 투명성(CT) 시행을 시행할 예정임을 다시 한번 말씀드리고 싶습니다. CA/B 포럼[2]에서 처음 발표된 것처럼, 이후 mozilla.dev.security.policy 포럼[3]에서 발표되고 나중에 참조된 ct-policy 포럼[4]에서 업데이트되면서 Chrome이 시작될 것입니다. 2018년 4월 이후 발급된 모든 TLS 인증서는 신뢰할 수 있도록 Chromium CT 정책[5]을 준수하도록 시행되었습니다.

2015년 1월부터 Chrome에서는 EV 상태를 획득하기 위해 CT 요구 사항을 충족하기 위해 EV(확장 유효성 검사) 인증서가 필요합니다. 2018년 4월에 이 요구 사항은 새로 발급된 모든 공개 신뢰 인증서(DV, OV, EV)로 확대되며 Chrome 평가 시 이 정책을 준수하지 않는 인증서는 신뢰할 수 있는 것으로 간주되지 않습니다. 신뢰할 수 있는 로컬 CA 또는 사용자나 관리자가 추가한 엔터프라이즈 CA에서 발급한 인증서에는 이 요구 사항이 적용되지 않습니다.

언제, 무슨 일이 일어났나요?

Chrome에서는 Chromium CT 정책을 준수하기 위해 2018년 4월 30일 이후에 발급된 모든 TLS 서버 인증서가 필요합니다. 이 날짜 이후에 Chrome이 Chromium CT 정책을 준수하지 않는 공개적으로 신뢰할 수 있는 인증서를 제공하는 웹사이트에 연결하면 사용자는 해당 연결이 CT를 준수하지 않음을 나타내는 전체 페이지 전면 광고를 보게 됩니다. CT를 준수하지 않는 https 연결을 통해 제공되는 하위 리소스는 로드되지 않고 Chrome DevTools에 오류가 표시됩니다. CA는 3월 말 이전에 고객과 협력하여 TLS 인증서가 RFC 6962 섹션 3.3[6]에 지정된 세 가지 방법 중 하나로 Chromium CT 정책을 준수할 준비가 되었는지 확인하여 발생하는 모든 문제를 확인하는 것이 좋습니다. 배포 중 CT 지원은 실행 마감일 전에 해결됩니다. 이러한 변경 사항은 macOS, Windows, Linux 및 ChromeOS를 포함한 데스크톱 플랫폼에 먼저 출시됩니다.

일부 기업의 고유한 요구 사항을 해결하기 위해 Chrome 정책에서는 관리 기기 및 개인 기기에서 Chrome에 로그인하는 관리 사용자에 대한 CT 시행을 금지합니다. URL[7]을 통해 CT 시행을 비활성화하는 기존 기능 외에도 Chrome은 조직이 해당 조직에 인증서만 발급하는 CA에 대해 CT 시행을 비활성화할 수 있도록 허용하는 정책을 추가합니다.

~에서Chrome에서는 2018년 4월 이후 CT가 필요합니다.

Chrome에서는 Chromium CT 정책을 준수하기 위해 2018년 4월 30일 이후에 발급된 모든 TLS 서버 인증서가 필요합니다. ” 이는 SSL/TLS 인증서가 다음 조건 중 하나를 충족하여 CT 자격을 갖추어야 함을 의미합니다.

  • 검사 시 자격을 갖춘 로그의 SCT(서명된 인증서 타임스탬프), TLS 확장을 통해 제공되거나 스테이플된 OCSP 응답에 포함됨, 검사 시 자격을 갖춘 Google 로그의 SCT가 하나 이상, 비인증 로그의 SCT 하나 이상이 포함됨 - Google 로그의 SCT가 검사를 통과했습니다.

  • Google 로그에서 포함된 SCT 1개 이상, Google 이외 로그에서 포함된 SCT 1개 이상, 포함된 SCT 최소 개수를 포함하여 검사 시 적격한 로그에 포함된 SCT를 제공합니다.

그래서부터인증서 투명성 소개

서명 인증서 타임스탬프

인증서는 일반적으로 인증서를 발급한 CA에 의해 CT 로그에 제출되지만 사이트 소유자는 자신의 인증서를 로그에 제출할 수도 있습니다. SCT는 인증서 제출 시 인증서 로그의 응답으로, 이는 기본적으로 지정된 기간 내에 로그에 인증서를 추가하겠다는 약속입니다. 고객이 당사 웹사이트에 TLS 연결을 설정할 때 당사는 이 SCT를 고객에게 제공해야 하며, 이를 수행하는 방법은 3가지가 있습니다.

x.509v3 확장

사이트 운영자에게 SCT를 제공하는 기본 방법은 X.509v3 확장을 사용하는 것입니다. 즉, CA가 인증서에 서명하고 발급하기 전에 SCT를 인증서에 포함시키므로 사용자 측에서 작업이나 설정이 전혀 필요하지 않습니다. CA는 최종 단계에 서명하기 전에 인증서를 작성하여 사전 인증서로 CT 로그에 제출합니다. 로그는 사전 인증된 SCT로 응답하며, CA는 이를 인증서에 내장한 후 서명하여 사용자에게 발급할 준비를 합니다.

TLS 확장

SCT는 TLS 확장을 통해 호스트에서 연결 클라이언트로 전달될 수도 있습니다. 이는 signed_certificate_timestamp라는 확장을 사용하여 TLS 핸드셰이크 중에 수행되지만 호스트가 서버를 업데이트하고 SCT를 전달하도록 구성해야 합니다. 여기서 이점은 CA의 경우 인증서 발급 방식을 변경할 필요가 없지만 SCT TLS 확장의 안정적인 서버 구현을 기다리는 것이 사이트 운영자에게 좋지 않을 수 있다는 것입니다.

OCSP 바인딩

저는 일반적으로 인증서에 대한 해지 정보를 전달하는 데 사용되지만 CA에서 사이트 운영자에게 SCT를 전달하는 데에도 사용할 수 있는 OCSP 스테이플링의 팬입니다. 이는 발급 프로세스를 변경할 필요 없이 평소처럼 인증서에 서명 및 발급하고 OCSP를 통해 SCT를 제공할 수 있다는 점에서 CA의 또 다른 이점입니다. 그러나 서버가 안정적으로 OCSP 스테이플을 수행하고 핸드셰이크 중에 클라이언트에 SCT를 포함할 수 있어야 하기 때문에 이는 우리에게도 문제가 됩니다.

그 결과로 내 웹사이트 두 개가 생겼는데, 그 중 하나는 다음과 같습니다(예:www.digicert.com)는 SCT X.509 확장을 인증서에 직접 포함하며 서버 측에서 설정을 수정할 필요가 없습니다.

다른 사이트(예: multicert.com)에서는 CA 운영자가 X.509 스테이플링을 사용하기로 선택했기 때문에 Apache 웹 서버에 구성 변경이 필요했습니다.

Digicert에 관한 기사도 찾았습니다.Apache용 OCSP 바인딩

따라서 사이트가 OSCP 스테이플링과 함께 작동하도록 하려면 다음이 필요합니다.

  • Apache 버전이 2.3.3 이상입니다.

  • CA OCSP 서버와 통신하는 VM

  • 가상 호스트에 추가:

    <virtualhost...> 지시문 외부

     SSLStaplingCache shmcb:/tmp/stapling_cache(128000)

    <virtualhost...> 지시어 내에서

     SSLUseStapling on

    그리고 아파치를 다시 시작하세요.

Multicert에서 발급한 X.509 인증서를 사용하는 사이트를 변경한 후 Chrome에서는 해당 인증서가 두 사이트 모두에서 유효하다고 표시합니다.

당신은 또한 볼 수 있습니다Chrome Linux에 X.509 확장 프로그램, SCT가 표시되지 않습니다.

더 많은 기술적인 세부사항

또한 2018년 5월 1일 시간 기준이 어떻게 설정되었으며 기존 인증서는 어떻게 되는지에 대한 질문도 받았습니다. 온라인에 더 명확한 세부 정보가 부족하기 때문에 다음에서 Chromium 소스 코드를 다운로드했습니다.https://chromium.googlesource.com/chromium/src/사용 명령:

git clone https://chromium.googlesource.com/chromium/src

인증서 투명성 기능에 관심이 있는 사람들에게는 더 흥미로운 디렉토리가 components/certificate_transparency/가장 흥미로운 문서 파일 인 것 같습니다.net/docs/certificate-transparency.md

흥미로운 발췌net/docs/certificate-transparency.md

개요

인증서 투명성(CT)은 SSL/TLS 인증서 생태계의 여러 구조적 결함을 수정하도록 설계된 프로토콜입니다. 에 설명된 RFC 6962, 기록할 수 있는 공개 추가 전용 데이터 구조를 제공합니다.인증 기관 (캘리포니아). 인증서 로깅을 통해 대중은 특정 CA에서 어떤 인증서가 발급되었는지 확인할 수 있습니다. 이를 통해 사이트 운영자는 자신의 도메인에 대한 인증서가 발급된 시기를 감지하여 무단 발급을 확인할 수 있습니다. 또한 브라우저와 루트 저장소는 물론 더 넓은 커뮤니티가 CA에서 발행한 인증서를 검사하고 CA가 예상되거나 공개된 관행을 준수하는지 확인할 수 있습니다.

기초적인

인증서와 함께 제공되는 CT 정보가 여러 CT 로그에 기록되었음을 나타내는 경우 인증서는 인증서 투명성을 지원한다고 합니다. 이 CT 정보는 다음을 준수해야 합니다.Chrome의 인증서 투명성 정책. 때때로 CT를 "활성화"하는 사이트를 "CT 적격" 또는 "CT 공개" 인증서를 사용하는 것으로 지칭합니다.

크롬 정책

지난 몇 년 동안 Chrome에서는 점점 더 많은 공개적으로 신뢰할 수 있는 인증서에 대해 인증서 투명성을 요구해 왔습니다.

  • 2015년 1월 1일부터, Chrome에서는 인증서 투명성을 통해 모든 확장 검증 인증서를 공개해야 합니다. 제대로 공개되지 않은 인증서는전기차 지위 박탈, 그러나 규정을 준수하지 않는 사이트 방문자에게는 경고가 표시되지 않습니다.

  • 2016년 6월 1일부터, Chrome에서는 Symantec이 소유한 루트 인증서 세트에서 발급된 모든 새 인증서가 인증서 투명성을 통해 공개되도록 요구합니다. 공개되지 않거나 RFC 6962와 일치하는 방식으로 공개되지 않은 인증서는 신뢰할 수 없는 것으로 거부됩니다.

  • 2018년 4월 30일 이후 발급된 모든 신규 인증서의 경우,Chrome에서는 인증서 투명성을 통해 인증서가 노출되도록 요구합니다.. 이 날짜 이후에 인증서가 발급되고 인증서나 사이트에서 CT를 지원하지 않는 경우 해당 인증서는 신뢰할 수 없는 것으로 거부되고 연결이 차단됩니다. 홈페이지가 로드되면 사용자는 오류 코드가 포함된 전체 페이지 인증서 경고 페이지를 보게 됩니다 net::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED. 이 오류가 발생하면 CA에서 인증서가 CT를 지원하는지 확인하는 조치를 취하지 않은 것이므로 CA의 영업 또는 지원 팀에 문의하여 유효한 대체 인증서를 얻을 수 있는지 확인해야 합니다.

도메인 개인정보 보호

CT 로그에 인증서를 공개하여 CT를 지원한다는 것은 인증서의 전체 내용이 공개적으로 액세스되고 볼 수 있음을 의미합니다. 특히 이는 인증서가 속한 도메인과 인증서가 속한 조직이 도메인 유효성 검사보다 높은 수준의 유효성 검사를 갖고 있거나 조직별 CA에서 발급된 경우 인증서 투명성 로그에 포함된다는 것을 의미합니다.

참고: 흥미롭게도,RFC 6292~로써 정의 된실험적인

2018년 5월 1일의 임시 시작일과 관련하여 Chromium 코드(Chrome과 공통)에는 전환 Chrome/Chromium 코드에 표시될 마감 연도를 정의하는 하드 코딩된 특정 인스턴스가 있습니다. 이는 2018년 5월 1일 이전에 발급된 인증서의 다양한 동작을 설명합니다.

services/network/network_context.cc에서:

1525         // For old certificates (issued before 2018-05-01),
1526         // CheckCTRequirements() may return CT_NOT_REQUIRED, so we check the
1527         // compliance status here.
1528         // TODO(https://crbug.com/851778): Remove this condition once we require
1529         // signing certificates to have CanSignHttpExchanges extension, because
1530         // such certificates should be naturally after 2018-05-01.
1531         if (ct_verify_result.policy_compliance ==
1532                 net::ct::CTPolicyCompliance::CT_POLICY_COMPLIES_VIA_SCTS ||
1533             ct_verify_result.policy_compliance ==
1534                 net::ct::CTPolicyCompliance::CT_POLICY_BUILD_NOT_TIMELY) {
1535           ct_verify_result.policy_compliance_required = true;
1536           break;
1537         }

구성 요소/certificate_transparency/chrome_ct_policy_enforcer.cc에서:

217   // ... AND there is at least one embedded SCT from a Google Log once or
218   //   currently qualified;
219   // AND there is at least one embedded SCT from a non-Google Log once or
220   //   currently qualified;
221   // ...
222   //
223   // Note: This policy language is only enforced after the below issuance
224   // date, as that's when the diversity policy first came into effect for
225   // SCTs embedded in certificates.
226   // The date when diverse SCTs requirement is effective from.
227   // 2015-07-01 00:00:00 UTC.
228   const base::Time kDiverseSCTRequirementStartDate =
229       base::Time::UnixEpoch() + base::TimeDelta::FromSeconds(1435708800);
230   if (issuance_date >= kDiverseSCTRequirementStartDate &&
231       !(has_embedded_google_sct && has_embedded_nongoogle_sct)) {
232     // Note: This also covers the case for non-embedded SCTs, as it's only
233     // possible to reach here if both sets are not diverse enough.
234     return CTPolicyCompliance::CT_POLICY_NOT_DIVERSE_SCTS;
235   }

부록: 제가 조사를 한 후 찾은 내용 중 일부를 바탕으로 세부 사항은 다음과 같습니다.Chrome Linux에 X.509 확장 프로그램, SCT가 표시되지 않습니다.

SCT 확장https://www.digicert.com

디지털 인증서

OCSP 정의https://www.multicert.com

여러 인증서

관련 정보