인트라넷 용 CA 만들기

인프라가 작은 경우 , CA 실행에 대한 세부 정보 (예 : CRL 등)의 대부분은 무시할 수 있습니다. 대신 인증서에 서명 만하면됩니다.

이 프로세스를 관리 할 수있는 많은 도구가 있습니다. 몇 년 전에 작성하기도했습니다. 정말 간단한 것은 OpenVPN 프로젝트의 easy-rsa 입니다. “OpenSSL 명령 줄 도구를 둘러싼 매우 얇은 래퍼입니다. “많은 인증서를 관리하고 실제로 해지 및 항목을 처리 할 예정이라면 훨씬 더 복잡하고 기능이 완전한 유틸리티를 원할 것입니다. 이미 충분한 제안이 제공되었으므로 대신 “귀하가 수행하려는 작업의 기본 사항 만 고수하겠습니다.

하지만 여기에 기본 절차가 있습니다. OpenSSL로 설명하겠습니다. ,하지만 모든 시스템에서 가능합니다.

“루트”CA를 생성하여 시작하십시오. 자체 서명 된 인증서가 될 것입니다.이를 수행하는 방법에는 여러 가지가 있습니다. 이것은 하나입니다. 2048 비트 키가있는 10 년 인증서입니다.적절하게 숫자를 조정하십시오. 해싱 알고리즘에 대해 걱정한다고 말씀 하셨기 때문에 허용 가능한 것으로 서명되었는지 확인하기 위해 -sha256를 추가했습니다. AES-256을 사용하여 키를 암호화하고 있지만 이는 선택 사항입니다. . 인증서 이름 등을 입력하라는 메시지가 표시됩니다. 이러한 세부 정보는 루트 CA에 특히 중요하지 않습니다.

# First create the key (use 4096-bits if that"s what floats your boat) openssl genrsa -aes256 -out root.key 2048 # Then use that key to generate a self-signed cert openssl req -new -x509 -key root.key -out root.cer -days 3652 -sha256 

첫 번째 단계에서 키를 암호화 한 경우 다음 암호를 입력해야합니다. 두 번째로 사용하십시오. 생성 된 인증서를 확인하여 “Basic Constraints”아래에 “CA : TRUE”가 표시되는지 확인하십시오. 이것이 정말 당신이 걱정해야 할 유일한 중요한 부분입니다.

openssl x509 -text < root.cer 

좋습니다. 이제 인증서에 서명하겠습니다. 우리는 다른 키와 이번에는 요청이 필요합니다. 당신은 당신의 이름과 주소를 다시 물어볼 것입니다. 채우는 필드와 제공하는 내용은 귀하와 귀하의 애플리케이션에 달려 있지만 가장 중요한 필드는 “일반 이름”입니다. 여기에서 호스트 이름이나 로그인 이름 또는이 인증서가 증명할 모든 것을 제공합니다.

# Create new key openssl genrsa -aes256 -out client1.key 2048 # Use that key to generate a request openssl req -new -key client1.key -out client1.req # Sign that request to generate a new cert openssl x509 -req -in client1.req -out client1.cer -CA root.cer -CAkey root.key -sha256 -CAcreateserial 

이것은 root.srl이라는 파일을 생성합니다. 일련 번호를 똑바로 유지합니다. -CAcreateserial 플래그는 openssl에이 파일을 만들도록 지시하므로 서명 한 첫 번째 요청에이 파일을 제공 한 다음 다시는 제공하지 않습니다. 그리고 다시 한 번 확인할 수 있습니다. -sha256 인수를 추가합니다.

모든 작업을 수동으로 수행하는이 접근 방식은 제 생각에는 최선의 방법이 아닙니다. 상당한 규모의 작업을 실행하는 경우 이면 모든 인증서를 추적 할 수있는 도구를 원할 것입니다.

대신, 여기서 내 요점은 원하는 출력, 즉 인증서가 원하는 방식으로 서명되었음을 보여주는 것이 었습니다. 사용하는 도구에 의존하지 않고 해당 도구에 제공하는 옵션에 따라 달라집니다. 대부분의 도구는 강하고 약한 다양한 구성을 출력 할 수 있으며 원하는 수를 제공하는 것은 사용자에게 달려 있습니다. m 적절합니다. 오래된 기본값은 코스와 동등합니다.

댓글

• 그것 ‘ 클라이언트 인증서에 서명하는 것은 공개 부분 일뿐입니다. CA에서 개인 키를 전송하거나 생성해서는 안됩니다.
• 중간 CA 인증서 생성에 대한 답변을 확장 해 주시겠습니까? 감사합니다.
• @Andr é 중급 인증서는 확장 속성에 basicConstraints = CA:TRUE가 설정된 일반 인증서입니다. 마법은없고 또 다른 인증서입니다.
• @tylerl Dude, 당신은 멋집니다.
• 이 답변은 환상적이고 매우 도움이되었지만 추가 할 2017 업데이트가 있습니다. 이제 Chrome 및 기타 제품에는 x509v3 subjectAlternativeName 확장 프로그램이 필요합니다. 그렇지 않으면 CA 루트 인증서가 시스템에 제대로 설치되어 있어도 인증서가 유효하지 않은 것으로 간주합니다. 나는 올바른 해결책을 찾기 위해 얼마 동안 고심했습니다. 이 페이지는 저에게 매우 귀중했으며 저에게 퍼즐의 마지막 부분을 해결했습니다 : cmrg.fifthhorseman.net/wiki/SubjectAltName . IMO는 요청할 때와 달리 서명 할 때 SAN을 추가하는 것이 더 쉽고 공용 CA가 실제로 수행하는 것과 비슷합니다.

진심으로 CA가되고 싶다면 그렇게하는 것이 보안에 미치는 영향에 유의하십시오.

1. 인트라넷의 루트 CA를 생성하는 데 사용되는 개인 키는 말 그대로 금고에 갇혀 있어야합니다. 그리고 해당 금고에 대한 액세스는 물리적으로 모니터링되어야합니다.
2. 자체 서명 된 루트 CA를 사용하면 사용자가 키의 안전한 보호를 위해 실사를 수행하고 있다는 것을 신뢰할뿐만 아니라 처음에는 신뢰할 수없는 루트를 삽입해야합니다.
3. 이것은 또한 ID 관리 서비스가 처음에 존재하는 이유 인 인증서 체인의 외부 검증과 관련하여 OSCP 스테이플 링 기능을 손상시킵니다.

많은 사람들이 자신의 CA를 관리하는 이유를 다음과 같이 주장합니다. 데스크톱 빌드의 일부에 루트 CA가 포함되어 있거나 소수의 사용자를위한 회사 인트라넷 용입니다.

이 작업을 수행하는 것이 반드시 잘못된 것은 아니며 일부 이점을 제공 할 수 있습니다. 인증서 기반 ID 관리가 구축 된 확인 체인을 무효화하십시오.

자신의 루트 CA를 구현하기로 결정했다면 다른 루트 CA가 사용하는 것과 동일한 보안 관행을 따르십시오. 마지막으로 원하는 것은 누군가가 루트 CA에 사용되는 개인 키를 손상시키고 클라이언트에 대한 피싱 캠페인에 대한 인증서 서명을 시작하는 것입니다.

이에 대해 사용할 수있는 수많은 모범 사례 가이드, NIST ( 국립 표준 및 기술 연구소)는 컴퓨터 보안 주제에 대한 다양한 표준을 지원하는 협력 그룹입니다.

권장 자료 :
감사 (PDF)
재해 복구 (PDF)
공개 키 시스템 (PDF)
Sans Institute 소규모 PKI 배포

알겠습니다. 질문을 더 구체적으로 업데이트했습니다.

CA 사양에 맞게 openssl.cnf 파일을 구성하기위한 두 개의 문서 :

https://www.openssl.org/docs/apps/ca.html

https://www.openssl.org/docs/apps/config.html

원하는 답이 아닐 수도 있지만 모든 사람의 환경과 요구 사항이 다르기 때문에 좋은 예제 구성을 위해 CA 구현 범위를 정의해야합니다.

댓글

• 저기 ‘ 자신의 CA가 ‘ OCSP를 수행 할 수있는 이유가 없습니다. OpenSSL 명령 줄 도 수행 할 수 있습니다. ‘ s 가능한 가장 낮은 표시 줄에 대해.
• openssl 링크는 이제 404입니다.

저기 이것을 간단히 할 수있는 방법이 아닙니다. 쉽게 시작하는 데 도움이되는 몇 가지 도구가 있습니다.

예 :

• XCA
• EJBCA
• openssl

아무것도 EJBCA를 제외하고 전체 PKI를 설정하는 것은 간단하지 않습니다.

• XCA는 인증서를 생성, 서명 및 취소하기위한 그래픽 인터페이스를 얻는 작은 프런트 엔드 도구입니다.
• EJBCA 또는 Enterprise Java Beans 인증 기관은 엔터프라이즈를위한 전체 PKI 인프라를 수행 할 수있는 JBOSS / Jetty Webapp입니다.
• openssl은 기본 명령 줄 도구입니다. CA의 모든 오프라인 비트를 수행 할 수 있지만 검증은 수행 할 수 없습니다 (기본 설정). 당신은 그것으로 자신의 OCSP Verifier를 만들 수 있지만 당신은 그것을위한 “온라인”코드를 직접 만들어야합니다.

원하는 모든 것이 적절한 openssl 구성이라면. XCA는이를 생성하는 데 도움을 줄 수 있습니다. (openssl 구성 내보내기 기능이 있습니다.

댓글

• 이제 EJBCA에 사용할 수있는 VM 이미지가 있습니다. 그렇지 않으면 ” 설치가 간단하지 않은 “는 과소 평가로 간주 될 수 있습니다. 기본적으로 () 구성을 시도하는 거대한 ant 스크립트입니다. JBoss) 애플리케이션 서버는 고장날 수 있습니다 (그리고 제 경우에는 할 것입니다 ).
• VM 이미지는 또는 평가 목적이므로 프로덕션 서버에는 권장하지 않습니다.
• li>
• XCA를 살펴볼 수 있습니다. EJBCA는 확실히 옵션이 아닙니다. ‘ 웹 인터페이스는 불필요한 공격 표면을 추가하고 설정하기 더 어렵습니다. openssl.
• @Andr é EJBCA와 관련하여 명령 줄에서도 사용할 수 있으므로 이겼습니다 ‘ 웹 인터페이스를 노출 할 필요는 없습니다.하지만 ‘ 엔터프라이즈 수준의 일이며 목적에 맞지 않을 수도 있습니다. es (그리고 나는 그것으로 일하는 생계를 유지하는 사람이라고 말합니다).

일부 좋은 배경입니다. 저의 프레젠테이션 자신 만의 인증서 관리 센터를 구축하고 운영하는 방법 을 참조하십시오. 프레젠테이션의 요점은 가장 필요한 것은 “실행할 명령 목록이 아니라 상업용 CA 운영에 들어가는 모든 다양한 컨트롤, 이들이 함께 상호 작용하는 방식, 제거 할 때의 정확한 영향에 대한 깊은 이해입니다. 그 중 하나는 여러 가지 제거로 인한 누적 영향과 감소 된 보안을 보완하는 데 필요한 완화 제어입니다.

이것이 “간단한 CA 설정에 대한 정식 답변”이없는 이유입니다. 키 서명 당사자, 에어 갭 및 보관 된 중복 루트 인증서, 여러 중간 서명자, 해지 서버 등으로 시작하여 전체 ISO 경로로 이동하거나 고유 한 비용 / 이점 및 위험을 기반으로 일부 타협을 고안해야합니다. 회사가 기꺼이 받아 들일 수있는 프로필 정의에 따라 평가할 수있는 충분한 기술과 경험을 가진 사람은 치트 시트가 필요하지 않습니다. 수행 할 비즈니스 기능과 해당 요구 사항을 구현하는 데 사용되는 보안 기본 요소에 대한 깊은 이해를 기반으로 올바른 명령 구문을 구문 분석 할 수 있습니다.

프레젠테이션에는이 길을 갔고 끔찍하게 잘못한 상점의 실제 참여 이야기가 있습니다. 어떤 경우에는 미들웨어 보안으로 내가 할 수있는 일이 내부 CA의 내재 된 약점을 극복 할 수있는 것이 전혀 없다고 내 평가가보고했습니다. 미국에있는 모든 사람은 프레젠테이션이 언급하는 공급 업체 중 하나 이상으로부터 서비스를 구매할 가능성이 있음을 알아야합니다. 이들은 은행, 신용 조합, 건강 보험사, 소매 업체 등입니다.

권장 사항이 “정확”하려면 응답자가 귀하의 허용 가능한 위험 프로필에 대해 주요 가정을하고 귀하와 귀하의 위험에 대한 아이디어가 일치하는 정도에 대한 주요 가정을해야하기 때문에 동시에, 그 제안은 그 얼굴에 위험합니다. 대부분의 경우 제공된 자습서의 적합성 평가는 절차를 따름으로써 발생하는 효과적인 보안 수준보다는 프레젠테이션과 더 관련이 있습니다. 잘 조직되고 명확하게 표현된다면 이것이 효과적인지 여부보다 훨씬 더 중요합니다. 우리는 가장 잘 보이는 표준 치트 시트를 선택합니다.

이러한 이유로 신뢰할 수있는 전문가가 “올바른 최신 파일 을 제공하지만 요구 사항과 허용 가능한 위험을보다 완전하게 평가하기위한 평가 프로세스를 제공 할 수 있습니다. 결과에 대해 비즈니스에 베팅하기 때문에 신뢰할 수있는 전문가는 당신이 얻는 모든 추천은 거의 정의상 신뢰할 수있는 전문가의 것이어야합니다. 행운을 빕니다.

댓글

• 내부 리소스를위한 인트라넷의 경우에도 프레젠테이션이 자신의 것임을 나타낼 수도 있습니다.
• ” 내부 리소스 용 인트라넷? ” 특히 그 이후 인트라넷 용 ‘ 대부분의 데이터 침해가 발생하는 위치입니다. ” 프레젠테이션은 귀하의 것입니다. ” 평가를 수행 한 경험을 설명 할 때 생각했지만 요점을 받았습니다. ‘ 업데이트했습니다.

팔로우하기 Windows 기반 CA 구성 지침. 클라이언트 인증서를 발급하므로 XP에서는 SHA2 해시가 지원되지 않습니다.

간단한 대답은 다음과 같습니다.

1. AD 설치
2. 도메인 컨트롤러에 엔터프라이즈 CA 설치
3. 최종 사용자 인증서를 발급하도록 인증서 템플릿 편집 (사용자가 자체 등록 할 수있는 권한을 설정하거나 웹 페이지로 이동)
4. 사용자를 확인하는 모든 서버에 루트 인증서 공개 키 배포
5. 사용자가 AD에있는 경우 GPO를 사용하여 자동 등록 활성화