ERR_SSL_KEY_USAGE_INCOMPATIBLE: 잘못된 인증서 용도

Problem

Firefox에서는 열리고 openssl s_client도 깔끔히 답하는 사이트가, Chrome과 Edge에서는 ERR_SSL_KEY_USAGE_INCOMPATIBLE로 거부됩니다. 인증서는 만료되지 않았습니다. 호스트명은 맞습니다. 체인은 신뢰된 루트로 빌드됩니다. Chrome은 인증서를 누가 서명했는지나 누구 이름인지에 이의를 제기하는 게 아닙니다 — 인증서가 자신의 키가 무엇을 하도록 허가되었다고 말하는지에 이의를 제기합니다.

Symptoms

• 실패가 Chrome/Edge 전용입니다; Firefox·Safari·curl은 불평 없이 연결될 수 있습니다.
• 서버나 인증서 변경 없이 Chrome 업데이트 이후 시작되었습니다.
• 대상이 흔히 내부 어플라이언스, IIS 서버, NAS, 프린터, 라우터 관리 페이지, 또는 자체 서명·내부 CA 인증서를 쓰는 무언가입니다.
• openssl s_client -connect host:443가 핸드셰이크를 완료하고 체인을 출력하는데 — 그래도 Chrome은 막습니다.
• 다른 Chrome 인증서 오류(ERR_CERT_AUTHORITY_INVALID, ERR_CERT_COMMON_NAME_INVALID)가 아니라, 메시지가 구체적으로 키 용도에 관한 것입니다.

What This Error Actually Means

X.509 인증서는 확장 두 개로 자기 키를 제약할 수 있습니다. Key Usage(RFC 5280 §4.2.1.3)는 키가 수행할 수 있는 암호 연산 — digitalSignature, keyEncipherment 등 — 을 지정하는 비트필드입니다. Extended Key Usage(§4.2.1.12)는 각각 OID로 된 상위 용도를 지정합니다: TLS 서버 인증은 id-kp-serverAuth, OID 1.3.6.1.5.5.7.3.1입니다.

ERR_SSL_KEY_USAGE_INCOMPATIBLE는 Chrome이 말하는 것입니다: 그 확장 중 하나가 존재하며 이 인증서를 TLS 서버로 쓰는 것과 모순된다. 같은 문제의 두 형태:

1. EKU가 있지만 serverAuth를 포함하지 않는다. 클라이언트 인증, 코드 서명, 이메일용으로 발급된 — 또는 잘못된 용도로 범위가 잡힌 CA 템플릿에서 나온 — 인증서는 1.3.6.1.5.5.7.3.1을 나열하지 않는 Extended Key Usage를 답니다. Chrome은 이걸 “이 키는 TLS 서버용이 아니다”로 읽고 멈춥니다.
2. Key Usage 비트가 핸드셰이크와 안 맞는다. 서버의 키 교환 방식이 필요한 비트를 결정합니다. ECDHE cipher suite — 그리고 TLS 1.3 전부 — 는 서버가 키 교환에 서명하므로 digitalSignature가 필요합니다. 레거시 RSA 키 전송 suite는 클라이언트가 서버 공개키로 암호화하므로 keyEncipherment가 필요합니다. 인증서가 keyEncipherment만 나열하는데 연결이 ECDHE(digitalSignature 필요)를 협상하면, 선언된 용도와 실제 연산이 어긋나고 Chrome이 거부합니다.

진단을 가능케 하는 핵심: 확장이 없으면 관대하고, 있는데 틀리면 치명적이다. RFC 5280은 Key Usage 확장이 없는 인증서는 무엇에든 쓸 수 있다고 말합니다; 문제는 확장이 존재하며 TLS가 필요로 하는 것을 금지할 때만 생깁니다. 그래서 이건 신뢰나 이름 문제가 아니고 클라이언트에서 고칠 수 없습니다 — 인증서가 자신에게 잘못된 일을 선언하고 있고, 그 선언을 바꾸는 건 재발급뿐입니다.

Top 3 Causes

1. 기본 설정으로 생성된 자체 서명 인증서. Windows New-SelfSignedCertificate, 오래된 IIS 자체 서명 인증서, 어플라이언스가 생성한 인증서는 흔히 digitalSignature나 serverAuth를 빠뜨립니다. Chrome이 시행을 시작하기 전까지는 됐고, 이제 모든 ECDHE/TLS 1.3 핸드셰이크 — 즉 모든 현대 핸드셰이크 — 가 키 용도 검사에 걸립니다.
2. 내부 CA의 잘못된 인증서 템플릿. 엔터프라이즈 PKI에서 “Computer”, “Code Signing”, 클라이언트 인증 템플릿으로 발급된 인증서는 serverAuth를 포함하지 않는 EKU를 답니다. 설치는 잘 되고, 신뢰된 내부 루트로 체인되고, 호스트명도 맞습니다 — 그래도 Chrome은 선언된 용도가 틀려서 거부합니다.
3. 의도된 용도 밖에서 재사용된 인증서. 누군가 클라이언트 인증이나 다른 역할로 발급된 인증서를 TLS 서버에 물립니다. 키 연산은 유효하고 체인은 신뢰되지만, EKU가 “서버 아님”이라고 하므로 Chrome은 서버용으로 쓰지 않습니다.

Diagnose with DechoNet

• SSL 진단은 서버가 실제로 제시하는 인증서를 읽어 브라우저 밖에서 그 필드를 보여줍니다. Extended Key Usage를 보세요 — serverAuth(또는 TLS Web Server Authentication)가 없으면, 다른 어떤 클라이언트가 뭐라 하든 그게 답입니다.
• 같은 진단이 체인의 각 인증서를 보여주므로, 문제가 위쪽의 무언가를 오독한 게 아니라 leaf(서버 인증서)에 있음을 확인할 수 있습니다. 여기서의 키 용도 거부는 종단 개체 인증서의 선언된 용도에 관한 것입니다.
• Chrome·Firefox·OpenSSL이 엄격성에서 서로 다르므로, 원시 인증서 필드를 외부에서 뜯어보는 것이 “curl에서는 된다”보다 낫습니다. 선언된 용도를 TLS 1.3/ECDHE 핸드셰이크가 필요로 하는 것(digitalSignature, EKU 내 serverAuth)과 대조하세요 — 그 대조가 진단의 전부입니다.

Resolution Checklist

• leaf 인증서의 Key Usage와 Extended Key Usage를 뜯어본다. EKU가 serverAuth(OID 1.3.6.1.5.5.7.3.1)를, Key Usage가 digitalSignature를 포함하는지 확인하세요. 둘 중 하나라도 없으면 그게 버그입니다.
• 올바른 용도로 인증서를 재발급한다. TLS 서버라면 keyUsage = digitalSignature(레거시 RSA 키 전송 cipher를 여전히 서빙할 때만 keyEncipherment 추가)와 serverAuth를 담은 EKU를 요청하세요. 이게 진짜 수정입니다 — 클라이언트 쪽 어떤 것도 이를 대체하지 못합니다.
• 내부 CA에서는 TLS 서버 템플릿을 고른다. Computer·코드 서명·클라이언트 인증 템플릿이 아니라 “Web Server” 템플릿(또는 CA의 상응물)에서 재발급해, 나오는 EKU가 맞게 하세요.
• 자체 서명 인증서는 용도를 명시해 재생성한다. New-SelfSignedCertificate나 openssl req를 쓸 때, 빠뜨릴 수 있는 기본값에 기대지 말고 키 용도와 serverAuth EKU를 명시적으로 설정하세요.
• curl만이 아니라 외부에서 검증한다. 외부 SSL 진단을 다시 돌려 이제 serverAuth가 나타나고 Key Usage가 협상된 교환을 허용하는지 확인하세요. openssl s_client 통과만으로는 Chrome이 수용하리란 증명이 안 됩니다.
• “신뢰”로 우회하려 들지 않는다. 인증서를 신뢰 저장소에 추가하면 authority 오류는 고쳐지지만 키 용도 오류는 아닙니다 — 용도는 인증서에 구워져 있고 재발급만이 바꿉니다.

When to Escalate

• 인증서가 재발급할 수 없는 어플라이언스·프린터·벤더 장비의 것이면 벤더에 에스컬레이션하세요: 수정은 serverAuth와 digitalSignature를 내보내는 펌웨어나 장비측 인증서 재생성입니다.
• 엔터프라이즈 CA에서 온 것이면 PKI 템플릿을 소유한 사람에게 넘기세요 — 교정은 웹 서버 템플릿에서의 새 발급이지, 개별 서버 관리자가 로컬에서 패치할 수 있는 게 아닙니다.