SHA-1이 더 이상 사용되지 않으므로 CA 루트 인증서가 모두 SHA-1로 서명 된 이유는 무엇입니까?

67

더 이상 SHA-1을 사용하여 SSL 인증서에 서명 할 수 없음을 이해합니다. 그러나 모든 CA 루트 인증서에는 SHA-1 서명 (대부분)이 있습니다. 더 이상 "You grandma SSL shop"에서 신뢰할 수없는 동일한 알고리즘이 세계 최고의 보안 인증서에 적합하다는 의미입니까?

뭔가 빠졌습니까? (키 사용법? 키 크기?)

ssl ssl-certificate certificate-authority

— 131
소스

9

"모든"CA 루트 인증서가 SHA1이라는 것은 사실이 아닙니다.

— Greg Askew

5

루트 인증서는 세계관에서 시작되는 가정과 같습니다. 그들을 신뢰하려면 믿음이 필요합니다.

— Roy Tinker

cogito ergo sum을 제외한 @RoyTinker (근본 의심, 대답 : 직교 회의론 )?

— Nick T

1

크로스 스택 : security.stackexchange.com/questions/120301/… 및 superuser.com/questions/1122069/…

— dave_thompson_085

6

@NickT는 : 플레이 그것은 안전 - 코기토 에르고 코기토 ;-)

— tonysdg

106

루트 CA 인증서의 서명은 확인할 필요가 없으므로 전혀 중요하지 않습니다. 그들은 모두 자기 서명입니다.

루트 CA 인증서를 신뢰하는 경우 서명을 확인할 필요가 없습니다. 당신이 그것을 신뢰하지 않으면, 그 서명은 당신에게 가치가 없습니다.

편집 : 아래에 매우 관련있는 의견이 있습니다. 나는 그것들을 복사하거나 바꾸거나 저자 대신에 그들을 대변하는 것을 느낀다. 그러나 나는 사람들 이이 답변에 설명을 추가하는 것을 환영합니다.

— 사용자 2233709
소스

3

왜 서명을했는지에 대한 의문을 가져옵니다

— Richard Tingle

42

시스템이 서명되지 않은 인증서를 지원하지 않기 때문입니다.

— OrangeDog

깨지기 쉬운 루트 인증서에 대한 우려는 "너는 루트 인증서를 어디서 얻었는지 모르는"것이 아니라 "누가이 인증서를 해독하여 사용할 수 있는지를 모릅니다" 원하는대로 서명하십시오. " 그리고 당신의 대답에서 두 (인증서 및 인증서 서명)는 별도의 관심사이며 인증서 자체는 적절하고 안전합니다.

— Dewi Morgan

20

"확인할 필요가 없습니다"보다 더 나아갈 것입니다. 인증서 체인에서 서명의 목적은 높은 권한이 낮은 권한을 인증하는 것입니다. 루트 CA의 경우 정의에 따라 더 높은 권한 ( "루트"의 의미)이 없으므로 인증서에 서명 할 수있는 사람이 없습니다 . 앞에서 언급했듯이 인증서에 서명 해야 하므로 루트 CA는 "더미"서명으로 서명되며 가장 간단한 방법은 자체 서명하는 것입니다. 따라서 확인할 필요가 없을뿐 아니라 루트 CA의 서명을 확인 한다는 아이디어 는 의미가 없습니다 .

— Jörg W Mittag

13

@DewiMorgan 클라이언트 는 (자체) 서명이 아니라 인증서 자체를 신뢰하기 때문에 해시 충돌로 루트 인증서를 "크랙"할 수 없습니다 . 해시 알고리즘이 아닌 RSA에 대한 공격 인 개인 키를 복구해야합니다.

— zwol

46

하루가 끝나면 루트 인증서가 자체 서명됩니다. 자체를 제외하고 다른 엔티티가 서명하지 않습니다. 루트 인증서는 신뢰할 수있는 게시자의 브라우저 목록에 제출하거나 Microsoft에서 기본 Windows 신뢰할 수있는 게시자 목록에 삽입하도록 허용하는 등의 대역 외 프로세스를 통해 신뢰를 얻습니다.

이 인증서 (및 자체 서명 한 회사)는 단순히 서명 이외의 다른 수단을 통해 철저하게 조사됩니다.

— 마크 헨더슨
소스

2

말할 것도없이, 루트 인증서를 업데이트하려면 대역 외 프로세스를 다시 수행해야합니다.

— Kaithar

4

"긍정적으로, 희망적으로"+1

— Nathan Osman

6

중요한 것은 SHA-1이 루트에 서명 한 경우 SHA-1에 의해 취소 될 수 있다는 것입니다. 즉, SHA-1을 공격 할 수있는 사람은 루트에 대한 해지를 구성 할 수 있습니다. 그리고 브라우저가이를 유지하는 방법을 알지 못하므로 파괴자는 SSL 연결을 끊는 것 이상을 달성하지 못했습니다. 절름발이

— 조쉬 슨
소스

1

이것은 흥미로운 생각이지만 이것이 이런 식으로 작동하는지 의심합니다. 내 생각에 각 에이전트는 고유 한 동작을 수행하지만 모든 개발자가 해지 목록을 사용하여 루트 인증서 해지를 관리 할 것이라는 생각은 의심 할 것입니다. 최소한, 이것이 어떤 경우에 효과가 있었다면, 개발자가 의도적으로가 아니라 소프트웨어 취소의 추상화 때문일 것입니다.

— Peter Oehlert

1

이것에 대한 메모로서, 일부 CA는 이미 루트 및 중간 인증서를 SHA256으로 업데이트하고 있습니다.

작년에 GlobalSign이 코드 서명 인증서를 업데이트하면서 인증서를 업데이트하고 있다는 것을 알고 있으므로 새 체인도 추가해야했습니다.

업데이트 된 특정 인증서와 업데이트 된 인증서를 확인할 수 있지만 여기서는 기존 SHA1 인증서를 남겼습니다. => 1

희망이 도움이됩니다.

— 카 카츠
소스

0

루트 CA의 경우 자체 서명에 관계없이 CRT에 번들로 제공되는 CA의 공개 키를 신뢰하게됩니다.

원시 공개 키 대신 .CRT 파일 형식을 사용하여 CA를 설명합니다.

— 131
소스

-1

있습니다 시대 대부분 2006 또는 이전, 아주 오래된 이미 고정 된 신뢰 SHA1 루트 브라우저에서 허용 인증서 있지만 어떤 새로운 인증서. Firefox와 Chrome이 한 자리 숫자를 사용하여 버전이 지정된 시점을 기억하십니까?

루트 CA가 Not Before가 2014 이후로 설정된 SHA1 인증서를 사용하는 경우 인증서가 실패합니다. 실제 날짜 제한은 브라우저 또는 다른 응용 프로그램에 따라 다릅니다. WebCA cabforum은 몇 년 전에 이것을 분명히했습니다. 다음을 통해 직접 테스트하십시오.

SHA1으로 서명 된 개인 루트 인증 기관 인프라를 작성하고이를 rootSHA1이라고합니다.
rootSHA1이 루트에 연결된 인증서로 인증서를 발행하는 "발급"CA 또는 "중간"CA를 작성하도록하십시오. 이를 중간 SHA256이라고합니다.
중간 SHA256 발급 CA가 sha256 이상의 해시로 서명 된 인증서를 생성하도록하십시오. 이를 webServerSHA256이라고합니다.
webServerSHA256을 webServerSHA56.mydomain.com에 설치하십시오.
rootSHA1, 중간 SHA256 및 webServerSHA256 인증서를 Chrome의 적절한 위치에 설치하십시오. 인증 체인을 사용하여 신뢰할 수있는 루트 인증 기관 및 다른 사람에게 루트를 설치하십시오.
Chrome을 https://webServerSHA256.mydomain.com/으로 이동 하고 webServerSHA256에 대한 녹색 자물쇠가 없는지 확인 하십시오 . 테스트가 실패합니다.

— rjt
소스

이것은 매우 잘못되었습니다. 중간 인증서 (및 EE./leaf 인증서)에는 SHA2가 필요하지만 루트에는 필요하지 않습니다. Google의 자체 인증서 체인은 개인 CA (Google Internet Authority G3)를 통해 SHA1 인 GlobalSign Root CA R2에 연결되며 Chrome에서도 허용됩니다.

— dave_thompson_085

예. 고정 된 SHA1 인증서는 허용되지만 자체 신뢰할 수있는 루트 인증서 저장소에 추가하더라도 새 SHA1 루트 인증서는 허용되지 않습니다. 내 답변에 테스트 사례를 추가했습니다.

— rjt