필터 기준: compliance x 지우기
compliance

Browser support ending for TLS 1.0 and 1.1

In 2020, the four major browsers are ending support for Transport Layer Security (TLS) 1.0 and 1.1.

This change doesn't affect your DigiCert certificates. Your certificates will continue to work as they always have.

What you need to know

This change affects browser-dependent services and applications relying on TLS 1.0 or 1.1. Once browser support for TLS 1.0 or 1.1 ends, these out-of-date systems will be unable to make HTTPS connections.

What you need to do

If you are affected by this change, plan to enable or upgrade to TLS 1.2 or TLS 1.3 now. Give yourself lead time to deal with any problems. Before you start, make sure to identify all systems that might use TLS 1.0 or 1.1.

Remember to check web servers like Apache or Microsoft IIS, .NET Framework, server monitoring agents, and other commerce applications that might use it.

Helpful resources

With so many different types of systems relying on TLS, we can't cover all available upgrade paths, but here are a few references that may help:

compliance

Apple의 비공개 SSL 인증서에 대한 새 컴플라이언스 요구 사항

Apple은 최근에 iOS 13 및 macOS 10.15를 릴리스하면서 적용되는 SSL/TSL 인증서에 대한 일부 새 보안 요구 사항을 발표했습니다. 이 요구 사항은 2019년 7월 1일 이후에 발급된 공개 및 비공개 인증서에 영향이 있습니다.

공개 DigiCert SSL/TSL 인증서에는 필요한 작업이 없습니다.

DigiCert 공개 SSL/TSL 인증서는 이미 이 보안 요구 사항을 충족합니다. 공개 SSL/TSL 인증서는 이 새 요구 사항에 영향을 받지 않으며 iOS 13 및 macOS 10.15에서 신뢰를 받을 것입니다.

새로운 사항

Apple은 구조적으로 비공개 SSL/TSL 인증서에 영향을 주는 모든 SSL/TSL 인증서에 대해 추가 보안 요구 사항을 구현하고 있습니다. iOS 13 및 macOS 10.15에서 신뢰받는 인증서 요구 사항을 참조하십시오. DigiCert 비공개 SSL/TSL 인증서는 공개 인증서 요구 사항에 따라서 계정 관리자가 발급한 경우 이 요구 사항을 충족합니다.

아래에 비공개 SSL/TSL 인증서에 영향을 줄 수 있는 요구 사항의 목록을 제공했습니다. 다행히 Apple의 이 버전의 OS는 올해 가을 중에 릴리스될 예정입니다. 즉 준비할 시간이 있습니다.

  • 서명 알고리즘에 SHA-2 패밀리의 알고리즘을 사용해야 합니다. SHA-1 서명 인증서는 더 이상 SSL/TLS에 대해 신뢰되지 않습니다.
  • 825일 이하의 유효 기간이 있어야 합니다. 유효 기간이 825일 이상인 SSL/TSL 인증서는 더 이상 신뢰되지 않습니다.

이 요구 사항을 충족하지 않는 비공개 인증서가 있고 Apple iOS 및 macOS 신뢰가 비공개 인증서에 대해 필요한 경우, 2019년 7월 1일 이후에 발급된 비공개 SSL/TSL 인증서를 iOS 13 및 macOS 10.15의 일반 사용 이전에 최초로 발급하거나 다시 발급해야 합니다. SSL/TSL 인증서 재발급을 참조하십시오.

compliance

Firefox ending key generation support

With the release of Firefox 69, Firefox will finally drop support for Keygen. Firefox uses Keygen to facilitate generating key material for submitting the public key when generating Code Signing, Client, and SMIME certificates in their browser.

Note: Chrome already dropped support for key generation, and Edge and Opera never supported it.

How does this affect you?

After DigiCert issues your Code Signing, Client, or SMIME certificates, we send you an email with a link to create and install your certificate.

Once Firefox 69 is released, you can only use two browsers to generate these certificates: Internet Explorer and Safari. If company policy requires the use of Firefox, you can use Firefox ESR or a portable copy of Firefox.

For more information, see Keygen support to be dropped with Firefox 69.

Tips and tricks

  • You can still use Firefox 69 for client authentication. First, generate the SMIME certificate in IE 11 or Safari. Then, import the SMIME certificate to Firefox.
  • To bypass generating Code Signing, Client, or SMIME certificates in your browser, generate and submit a CSR with your order. Instead of a link, DigiCert will send you an email with your certificate attached.
new

We added a new status, Emailed to Recipient, to the Orders and Order Details pages, for Code Signing and Client certificate orders, making it easier to identify where these orders are in the issuance process.

This new status indicates the DigiCert has validated the order, and the certificate is waiting for the user/email recipient to generate it in one of the supported browsers: IE 11, Safari, Firefox 68, and portable Firefox.

(In the sidebar menu, click Certificates > Orders. Then, on the Orders page, click the order number for the Code Signing or Client certificate order.)

enhancement

We updated our Extended Validation (EV) Code Signing (CS) and Document Signing (DS) certificate reissue processes, enabling you to reissue these certificates without automatically revoking the current certificate (original or previously reissued certificate).

Note: If you don't need the current certificate (original or previously reissued certificate), you'll need to contact support so they can revoke it for you.

Now, the next time you reissue an EV CS or DS certificate, you can keep the previously issued certificate active to its current validity period (or for as long as you need it).

compliance

Industry standards compliance reminder

For public and private certificates, Certificate Authorities (CAs) don't accept abbreviations for these parts of an address in your certificate orders or organization pre-validation requests:

  • State or Province*
  • City or Locality*

*This applies to organization and jurisdiction addresses.

new

We made it easier to define the domain validation scope for your account when submitting your domains for validation (pre-validation or via certificate orders).

On the Division Preferences page, we added two domain validation scope options:

  • Submit exact domain names for validation
    With this option, requests for new domains are submitted for validation exactly as named (i.e., request for sub.example.com is submitted for validation exactly as sub.example.com). Validation for the “higher level” domain (e.g., example.com) also works. This is the default behavior for CertCentral.
  • Restrict validation to base domain only
    This option allows you to restrict domain validation to the base domain (e.g., example.com). For request that include new subdomains (e.g., sub.example.com), we only accept domain validation for the base domain (e.g., example.com). Validation for the subdomain (e.g., sub.example.com) won’t work.

To configure the domain validation scope for your account, in the sidebar menu, click Settings > Preferences. On the Division Preference page, expand Advanced Settings. In the Domain Control Validation (DCV) section, under Domain Validation Scope, you'll see the new settings.

fix

We fixed a bug where we were limiting the maximum allowed number of SANS to 10 on Wildcard SSL certificate reissue and new certificate orders.

Now, when reissuing or ordering a new Wildcard SSL certificate, you can add up to 250 SANs.

compliance

업계 표준 변경

2019년 7월 31일(19:30 UTC) 기준으로 인증서 IP 주소에 대한 제어를 증명하려면 HTTP 실제 증명 DCV 방법을 사용해야 합니다.

HTTP 실제 증명 DCV 방법에 대한 자세한 정보는 다음 설명을 참조하십시오.

현재 업계 표준에서는 다른 DCV 방법을 사용하여 IP 주소에 대한 제어를 증명할 수 있게 했습니다. 그렇지만 투표 SC7의 통과로 인해 IP 주소 유효성 검사에 대한 규제가 변경되었습니다.

투표 SC7: IP 주소 유효성 검사 방법 업데이트

이 투표는 고객의 인증서에 나열된 IP 주소의 제어를 유효성 검사하는 허용된 절차 및 방식을 다시 정의합니다. 투표 SC7에 대한 컴플라이언스 변경은 2019년 7월 31일(19:30 UTC)에 발효됩니다.

컴플라이언스를 유지하려면 2019년 7월 31일 (19:30 UTC)를 기준으로 DigiCert는 고객이 IP 주소 유효성 검사을 위해 HTTP 실제 증명 DCV 방법만 사용을 허용할 것입니다.

IPv6에 대한 지원 제거

2019년 7월 31일(19:30 UTC) 기준으로 DigiCert는 IPv6 주소의 인증서에 대한 지원을 제거했습니다. 서버 제한으로 인해 DigiCert는 HTTP 실제 증명 DCV 방법을 위해 IPv6 주소에 도달하여 고객의 웹사이트에 있는 파일을 확인할 수 없습니다.

enhancement

CertCentral SAML 페더레이션 설정을 업데이트하여 페더레이션 이름이 SAML Single Sign-On IdP 선택SAML 인증서 요청 IdP 선택 페이지의 IdP의 목록에 나타나지 않게 할 수 있습니다.

이제 페더레이션 설정 페이지의 IDP 메타데이터에서 페더레이션 이름 포함 옵션을 추가했습니다. 페더레이션 이름을 IdP 선택 페이지의 IdP 목록에 나타나지 않게 하려는 경우,, 나의 페더레이션 이름을 IdP의 목록에 추가을 확인 해제합니다.

new

Secure Site Pro TLS/SSL 인증서를 CertCentral에서 사용할 수 있습니다. Secure Site Pro에서는 도메인별로 청구하며 기본 인증서 비용은 없습니다. 한 개 도메인을 추가하면 한 개에 대해 청구됩니다. 9개 도메인이 필요하면 9개에 대해 청구됩니다. 한 개 인증서에서 최대 250개 도메인을 보호합니다.

두 종류의 Secure Site Pro 인증서(OV 인증서 및 EV 인증서)를 제공합니다.

  • Secure Site Pro SSL
    니즈에 적합한 OV 인증서를 받습니다. 한 개 도메인, 한 개 와일드카드 도메인 및 모든 하위 도메인에 대해 암호화 및 인증을 제공하거나 SAN(주체 대체 이름)을 사용하여 한 개 인증서로 여러 도메인 및 와일드카드 도메인을 보호합니다.
  • Secure Site Pro EV SSL
    니즈에 적합한 확장 유효성 검사 인증서를 받습니다. 한 개 도메인을 보호하는 암호화 및 인증을 제공하거나 SAN(주체 대체 이름)을 사용하여 한 개 인증서로 여러 사이트(정규화된 도메인 이름)를 보호합니다.

각 Secure Site Pro 인증서에 포함된 혜택

각 Secure Site Pro에는 추가 비용 없이 향후 CertCentral에 추가되는 프리미엄 기능에(예, CT 로그 모니터링 및 유효성 검사 관리) 우선적으로 액세스를 포함합니다.

이외 혜택은 다음과 같습니다.

  • 우선 순위 유효성 검사
  • 우선 순위 지원
  • 2개 프리미엄 사이트씰
  • 맬웨어 확인
  • 업계 최고의 보증

CertCentral 계정에 대해 Secure Site Pro 인증서를 활성화하려면 계정 매니저에게 연락하거나 저희 지원 팀에게 연락하십시오.

Secure Site Pro 인증서 대해 자세히 알아보려면 DigiCert Secure Site Pro를 참조하세요.

compliance

공개 SSL 인증서는 더 이상 밑줄("_")을 포함하는 도메인 이름을 보호할 수 없습니다. 모든 도메인 이름에 밑줄이 있는 이전에 발급한 인증서는 이 날짜 이전에 만료되어야 합니다.

참고: 밑줄에 대해 선호하는 솔루션은 밑줄을 포함하는 호스트 이름(FQDN)을 바꾸고 인증서를 교체하는 것입니다. 그렇지만 이름을 바꾸는 것이 불가능한 경우, 비공개 인증서을 사용할 수 있으며 일부 경우에는 전체 도메인을 보호하는 와일드카드 인증서를 사용할 수 있습니다.

자세한 정보는 도메인 이름에 밑줄 사용 중지를 참조하십시오.

compliance

ECC SSL/TSL 인증서에 CanSignHttpExchanges 확장 포함에 대한 업계 표준 요구 사항:

  • "cansignhttpexchanges=yes" 매개 변수를 포함하는 해당 도메인에 대한 CAA 리소스 레코드*
  • ECC(타원 곡선 암호화) 키페어
  • CanSignHttpExchanges 확장
  • 최대 90일 유효 기간*
  • 서명한 HTTP 교환에 대해서만 사용

*참고: 이 요구 사항은 2019년 5월 1일 기준으로 발효되었습니다. 서명한 HTTP 교환 확장은 활동적으로 개발이 진행 중입니다. 업계의 개발이 진행되면서 요구 사항에 추가 변경 사항이 있을 수 있습니다.

90일 최대 인증서 유효 기간 요구 사항은 2019년 5월 1일 이전에 발급된 인증서에 영향이 없습니다. 재발급 인증서는 재발급 시점에서 90일로 기간이 줄어듭니다. 그렇지만 전체 구입 유효 기간 동안 계속해서 인증서를 다시 발급할 수 있습니다.

CanSignHttpExchanges 확장

브랜드가 주소 표시줄에 표시되는 않는 AMP URL 표시 문제를 해결하기 위해 최근에 새 인증서 프로필 HTTP 서명 교환을 추가했습니다. 서명 교환으로 더 향상된 AMP URL 표시하기를 참조하십시오.

이 새 프로필은 OV 및 EV SSL/TSL 인증서에서 CanSignHttpExchanges 확장을 포함할 수 있게 합니다. 계정에서 사용하면 인증서에 CanSignHttpExchanges 확장 포함 옵션이 OV 및 EV SSL/TLS 인증서 요청 양식의 추가 인증서 옵션 밑에 나타납니다. 서명한 HTTP 교환 인증서 받기를 참조하십시오.

계정에 이 인증서 프로필을 사용하려면 계정 매니저에게 연락하거나 지원 팀에게 문의하십시오.

compliance

CA에서 더 이상 도메인 이름(일반 이름 및 주체 대체 이름)에 밑줄을 포함하는 30일 공개 SSL 인증서를 발급할 수 없습니다.

참고: 밑줄에 대해 선호하는 솔루션은 밑줄을 포함하는 호스트 이름(FQDN)을 바꾸고 인증서를 교체하는 것입니다. 그렇지만 이름을 바꾸는 것이 불가능한 경우, 비공개 인증서을 사용할 수 있으며 일부 경우에는 전체 도메인을 보호하는 와일드카드 인증서를 사용할 수 있습니다.

자세한 정보는 도메인 이름에 밑줄 사용 중지를 참조하십시오.

compliance

CA에서 도메인 이름(일반 이름 및 주체 대체 이름)에 밑줄을 포함하는 30일 공개 SSL 인증서를 주문할 수 있는 마지막 날짜.

참고: 밑줄에 대해 선호하는 솔루션은 밑줄을 포함하는 호스트 이름(FQDN)을 바꾸고 인증서를 교체하는 것입니다. 그렇지만 이름을 바꾸는 것이 불가능한 경우, 비공개 인증서을 사용할 수 있으며 일부 경우에는 전체 도메인을 보호하는 와일드카드 인증서를 사용할 수 있습니다.

자세한 정보는 도메인 이름에 밑줄 사용 중지를 참조하십시오.

compliance

사용자의 작업은 필요하지 않습니다.

2019년 2월 13일 현재 DigiCert는 더 이상 커브-해시 페어 P-384 및 SHA-2 512(SHA-512)의 ECC TLS/SSL 인증서(즉 ECDSA 키를 사용하는 인증서)를 발급하지 않습니다. 이 커브-해시 페어는 Mozilla의 루트 스토어 정책을 준수하지 않습니다.

Mozilla의 루트 스토어 정책은 다음 커브-해시 페어만 지원합니다.

  • P‐256 및 SHA-256
  • P‐384 및 SHA-384

참고: P-384 및 SHA-512 커브-해시 페어의 인증서를 가지고 있습니까? 걱정하지 마십시오. 인증서를 갱신할 때가 되면 지원하는 커브-해시 페어를 사용하여 자동으로 발급됩니다.

compliance

CA(인증 기관)는 이 날짜까지(UTC 시간) 최대 유효 기간이 30일 초과하는 밑줄을 포함하는(일반 이름 및 주체 대체 이름에) 모든 공개 SSL 인증서를 해지했습니다.

2019년 1월 14일 이후에 만료하는 31일 이상의 총 유효 기간이 있는 SSL 인증서가(1년, 2년 및 3년 인증서 포함) 있는 경우, 인증서를 발급한 CA는 해지해야 합니다.

자세한 정보는 도메인 이름에 밑줄 사용 중지를 참조하십시오.

compliance

DigiCert에서 제한된 기간 동안 밑줄을 포함하는 공개 SSL 인증서를 발급하기 시작했습니다.

  • 도메인 이름에 밑줄이 포함된 공개 SSL 인증서는 최대 30일 유효 기간이 있습니다.
  • 밑줄은 기본 도메인에 포함될 수 없습니다.(즉 "example_domain.com"은 허용되지 않음)
  • 밑줄은 가장 왼쪽 도메인 레벨에 포함될 수 없습니다.("_example.domain.com" 및 "example_domain.example.com"은 허용되지 않음)

자세한 정보는 도메인 이름에 밑줄 사용 중지를 참조하십시오.

new

상위 메뉴에 새로 2개의 지원팀 연락처 옵션(전화 및 채팅 아이콘)을 추가하여 CertCentral 내에서 지원팀에게 연락하기(이메일, 채팅 또는 전화를 통하여) 쉽게 했습니다.

전화 아이콘은 이메일 및 전화 옵션을 제공합니다. 채팅 아이콘은 전문 지원 팀 멤버와 채팅을 시작할 수 있는 채팅 창을 제공합니다.

enhancement

사이드바 메뉴를 향상하여, 방문하는 페이지에 대한 메뉴 옵션을 보기 쉽게 했습니다. 이제 CertCentral의 페이지를 방문할 때 페이지에 대한 메뉴 옵션 옆에 파란색 가로 바가 있습니다.

fix

인증서 주문의 일부분으로 추가 및 유효성 검사한 새 조직에 대해 유효성 검사 상태(EV 및 OV 유효성 검사)가 포함되지 않는 SSL/TSL 인증서 요청 양식에 조직 추가 기능에 버그를 수정했습니다.

이제 SSL 인증서를 주문할 때 추가되는 새 조직은 유효성 검사됨 상태를 표시할 것입니다.

참고: 조직의 유효성 검사 상태는 조직을 완전히 유효성 검사할 때까지 나타나지 않습니다.

compliance

업계 표준 컴플라이언스가 변경되었습니다. 공개 신뢰 인증서의 경우 하위 도메인에 더 이상 밑줄( _ )을 포함할 수 없습니다. RFC 5280에서 이제 하위 도메인에 대해서도 적용합니다.

일반에게 신뢰되는 인증서 – 업계 표준을 위반하는 데이터 엔트리를 참조하십시오.

8월 1, 2018

compliance

업계 표준이 변경되어 BR(기준 요구 사항)에서 2개의 DCV(도메인 제어 유효성 검사) 방법을 제거했습니다.

2018년 8월 1일부터 시작하여 인증 기관은 더 이상 다음 DCV(도메인 제어 유효성 검사) 방법을 사용하지 않습니다.

  • 3.2.2.4.1 신청자를 도메인 연락처로 유효성 검사
    이 방법으로 CA는 신청자가 직접 도메인 이름 등록 기관에게서 도메인의 연락처임을 확인하여 인증서 요청자의 SSL/TSL 인증서 주문의 도메인에 대한 제어를 유효성 검사할 수 있습니다.
  • 3.2.2.4.5 도메인 권한 부여 문서
    이 방법으로 CA는 도메인 권한 부여 문서에 포함된 해당 문서에 대한 인증서를 주문한 요청자의 권한 확인을 사용하여 SSL/TSL 인증서 주문의 도메인에 대한 제어를 유효성 검사할 수 있습니다.
    투표 218: 유효성 검사 1 및 5를 제거를 참조하십시오.

일부 사용 가능한 DCV 방법에 대해 자세히 알아보려면 DCV(도메인 제어 유효성 검사) 방법을 참조하십시오.

5월 25, 2018

compliance

DigiCert의 GDPR 컴플라이언스

GDPR(일반 데이터 보호 규정)은 EU 내의 모든 개인에 대한 데이터 보호 및 개인정보보호에 대한 유럽 연합의 법률입니다. 주요 목표는 EU의 시민 및 거주민에게 자신의 개인 정보에 대한 더 많은 컨트롤을 주고 EU 내의 규정을 통합하여 국제 비즈니스에 대한 규제 환경을 간소화하는 것입니다. GDPR은 2018년 5월 25일부터 발효되었습니다. 자세한 정보 »

DigiCert 설명

DigiCert는 GDPR을 이해하고 준수하기 위해 노력합니다. 당사는 GDPR이 2018년 5월 25일 발효되었을 때 요건과 정렬되어 있었습니다. GDPR(일반 데이터 보호 규정) 충족을 참조하십시오.

compliance

GDPR의 WHOIS 기반 이메일 DCV(도메인 제어 유효성 검사)에 영향

유럽 연합의 GDPR(일반 데이터 보호 규정)은 2018년 5월 25일 발효되었습니다. GDPR은 유럽 연합(EU) 내에 거주하는 개인(법인 이외)에 대한 데이터 보호를 요구합니다.

DigiCert는 ICANN과 협력하여 WHOIS 정보를 사용 가능하게 유지하고 있습니다. ICANN은 GDPR의 요건을 다루기 위한 몇 가지 변경 사항이 있지만 레지스트리 및 등록 기관이 WHOIS에 정보를 계속 제출을 요구할 것이라고 발표했습니다. WHOIS, GDPR 맟 도메인 유효성 검사에 대한 메모를 참조하십시오.

WHOIS 기반 이메일 도메인 유효성 검사에 의존하십니까?

도메인 등록 기관에게 CA가 GDPR 규정 준수의 일부분으로 WHOIS 데이터에 액세스하는 방법으로 익명 이메일 또는 웹 양식을 사용하고 있는지 확인하십시오.

가장 효율적인 유효성 확인 절차를 위해서는 등록 기관에게 계속해서 전체 게시된 레코드를 사용하거나 도메인에 대해 익명화된 이메일 주소를 사용하고 싶은지 알려 주십시오. 이 옵션을 사용하면 유효성 검사 프로세스에 최소한 영향 또는 전무한 영향이 있도록 보장합니다.

등록 기관에서 익명화 이메일 또는 웹 양식을 CA가 WHOIS 데이터에 액세스하는 방법으로 사용합니까? 그렇다면 DCV 이메일을 WHOIS 레코드에 나열된 주소로 보낼 수 있습니다.

등록 기고나에서 이메일 주소를 가리거나 제거합니까? 그렇다면 다른 방법 중 한 개를 사용하여 도메인에 대한 제어를 증명해야 합니다.

  • 지정된 이메일
  • DNS TXT
  • DNS CNAME
  • HTTP 실제 데모

지정된 이메일 주소 및 기타 대체 DCV 방법에 대한 정보는 DCV(도메인 제어 유효성 검사) 방법을 참조하십시오.

5월 10, 2018

compliance

업계 표준에서는 CA(인증 기관)가 "issue"/"issuewild" 속성 태그가 없는 CAA 레코드만 있는 도메인에 대한 SSL/TSL 인증서를 발급할 수 있게 합니다.

CA가 도메인의 CAA RR에 쿼리를 하고 "issue" 또는 "issuewild" 속성 태그가 없는 레코드를 찾으면 CA는 이것을 이 도메인에 대한 SSL/TSL 인증서를 발급하는 권한으로 해석할 수 있습니다. 투표 219: "issue"/"issuewild" 속성 태그가 없는 CAA 레코드 설정의 처리를 설명을 참조하십시오.

CAA RR 확인 절차에 대해 자세히 알아보려면 DNS CAA 리소스 레코드 확인 페이지를 참조하십시오.

4월 1, 2018

compliance

TLS 1.0/1.1을 사용하지 않으려는 업계 전반의 추세 및 PCI 컴플라이언스 유지를 위해 DigiCert는 2018년 4월 1일에 TLS 1.0/1.1을 사용 중지했습니다. DigiCert는 TLS 1.2 및 이후 더 높은 버전만 지원합니다. TLS 1.0 및 1.1 사용되지 않음을 참조하십시오.

3월 2, 2018

compliance

DigiCert에서 OU(조직 부서) 확인 절차를 구축했습니다.

기준 요구 사항에 따라서:

"CA는 섹션 11.2에 따라서 정보를 확인하지 않은 경우, CA는 OUR 속성에 이름, DBA, 상호, 상표, 주소, 위치 또는 기타 특정 개인 또는 법인을 지칭하는 텍스트를 OUT 특성에 포함되는 것을 방지하는 절차를 구현해야 합니다."

참고: OU 필드는 옵션 필드입니다. 인증서 요청에 조직 부서를 포함하는 것은 필수가 아닙니다.

compliance

2018년 3월 1일 현재 825일은 재발급(또는 복제 인증서 발급) 공개 3년 SSL/TSL 인증서에 대한 최대 허용된 길이입니다.

2017년 3월 1일 이후에 발급된 3년 OV 인증서의 경우, 3년 인증서 수명 주기의 첫 해 중에는 모든 재발급 및 복제 인증서는 "원본" 인증서보다 더 짧은 수명 주기를 갖고 있을 수 있으며 이 재발급 인증서가 먼저 만료될 것입니다.
이것이 나3년 인증서 재발급 및 복제 인증서 발급에 어떤 영향이 있습니까?를 참조하십시오.

2월 21, 2018

compliance

2018년 2월 21일 현재 DigiCert는 일반 SSL 인증서의 최대 길이를 825일(약 27개월)로 제한하는 업계 표준의 변경으로 인해 1년 및 2년 일반 SSL/TSL 인증서만 제공합니다. 2018년 2월 20일은 새로 3년 인증서를 주문할 수 있는 마지막 날을 참조하십시오.

compliance

이것은 오직 정보 목적이며 작업이 필요하지 않습니다.

2018년 2월 1일 현재, DigiCert는 모든 새로 발급한 일반 SSL/TLS 인증서를 공개 CT(인증서 투명성) 로그에 기록합니다. 이것은 2018년 2월 1일 이전에 발급한 OV 인증서에는 영향을 주지 않습니다. CT 로그는 2015년부터 EV 인증서에 대해 필수였습니다. DigiCert 인증서는 2월 1일부터 공개 로그에 기록을 참조하십시오.

enhancement

새 "인증서를 주문할 CT 로그에서 제외" 기능을 CertCentral에 추가했습니다. 이 기능을 활성화하면(설정 > 기본 설정) 계정 사용자가 인증서 주문별로 일반 SSL/TSL 인증서를 공개 CT 로그에 기록하기에서 제외할 수 있습니다.

SSL 인증서를 주문할 때 사용자는 SSL/TSL 인증서를 공개 CT 로그에 기록하지 않는 옵션이 있습니다. 이 기능은 사용자가 새 인증서를 주문, 인증서를 다시 발급 및 인증서 갱신할 때 사용 가능합니다. CertCentral 공개 SSL/TLS 인증서 CT 로깅 가이드를 참조하십시오.

enhancement

새 옵션 CT 로깅 옵트 아웃 필드(disable_ct)를 SSL 인증서 요청 API 엔드포인트에 추가했습니다. 또한 새 CT 로그 발급 인증서 옵트 아웃 엔드포인트(ct-status)를 추가했습니다. CertCentral API 공개 SSL/TLS 인증서 투명성 옵트 아웃 가이드를 참조하십시오.

10월 24, 2017

compliance

CAA 리소스 레코드 확인에 대한 업계 표준 변경. 8개 이하의 CNAME 레코드를 포함하는 CNAME 체인을 확인하는 절차를 변경했으며 검색은 CNAME 레코드의 대상의 부모를 포함하지 않습니다. DNS CAA 리소스 레코드 확인을 참조하십시오.

9월 8, 2017

compliance

인증서 발급에 대한 업계 표준 변경. DNS CAA 리소스 레코드를 확인하는 수정된 인증서 발급 절차. DNS CAA 리소스 레코드 확인을 참조하십시오.

7월 28, 2017

compliance

업계 표준 컴플라이언스 변경; 향상된 RFC 5280 위반 확인 및 적용. 일반에게 신뢰되는 인증서 – 업계 표준을 위반하는 데이터 엔트리를 참조하십시오.

7월 21, 2017

compliance

유효성 검사 절차에 대한 업계 표준 변경. 825일이 지난 유효성 검사 정보(DCV 또는 조직)은 인증서 재발급, 갱신 또는 발급을 처리하기 전에 다시 유효성 검사를 해야 합니다. 자세한 정보 »

7월 10, 2017

compliance

업계 표준 컴플라이언스 변경; 추가적 DCV(도메인 제어 유효성 검사) 방법 지원 추가. 도메인 사전 유효성 검사: DCV(도메인 제어 유효성 검사) 방법을 참조하십시오.