공개 키 인프라. 자가격리 중 증명서 발급

이 모든 시작하는 방법

자가 격리 기간이 시작될 무렵, 나는 우편으로 다음과 같은 편지를 받았습니다.

첫 번째 반응은 자연스러웠습니다. 토큰을 사러 가거나 토큰을 가져와야 하는데 월요일부터 우리는 모두 집에 앉아 있어서 이동 제한이 있는데 도대체 저 사람은 누구입니까? 그러므로 대답은 매우 자연스러웠습니다.

그리고 모두가 알고 있듯이 1월 11일 월요일부터 상당히 엄격한 자가 격리 기간이 시작되었습니다. 우리 모두는 원격 근무로 전환했고 VPN도 필요했습니다. 당사의 VPN은 OpenVPN을 기반으로 하지만 러시아어 암호화와 PKCS#12 토큰 및 PKCS#XNUMX 컨테이너 작업 기능을 지원하도록 수정되었습니다. 당연히 우리 자신도 VPN을 통해 작업할 준비가 되지 않은 것으로 나타났습니다. 많은 사람들이 인증서가 없었고 일부는 만료되었습니다.

과정은 어떻게 진행됐나요?

그리고 이것이 유틸리티가 구출되는 곳입니다. 암호화폐 및 적용 CAFL63 (검증센터).

cryptoarmpkcs 유틸리티를 사용하면 자가 격리 중이고 집 컴퓨터에 토큰이 있는 직원이 인증서 요청을 생성할 수 있습니다.

직원들이 이메일을 통해 저장된 요청을 나에게 보냈습니다. 누군가가 다음과 같이 질문할 수 있습니다. - 개인 데이터는 어떻습니까? 자세히 살펴보면 요청에 없습니다. 그리고 요청 자체는 서명으로 보호됩니다.

인증서 요청이 수신되면 CAFL63 CA 데이터베이스로 가져옵니다.

그 후에는 요청을 거부하거나 승인해야 합니다. 요청을 고려하려면 해당 요청을 선택하고 마우스 오른쪽 버튼을 클릭한 후 드롭다운 메뉴에서 "결정하기"를 선택해야 합니다.

의사결정 절차 자체는 완전히 투명합니다.

인증서는 동일한 방식으로 발급되며 메뉴 항목만 "인증서 발급"이라고 합니다.

발급된 인증서를 보려면 상황에 맞는 메뉴를 사용하거나 해당 줄을 두 번 클릭하면 됩니다.

이제 openssl(OpenSSL 텍스트 탭)과 CAFL63 애플리케이션의 내장 뷰어(인증서 텍스트 탭)를 통해 콘텐츠를 볼 수 있습니다. 후자의 경우 상황에 맞는 메뉴를 사용하여 인증서를 텍스트 형식으로 먼저 클립보드에 복사한 다음 파일에 복사할 수 있습니다.

여기에서 첫 번째 버전과 비교하여 CAFL63에서 변경된 사항이 무엇인지 주목해야 합니까? 인증서 보기에 관해서는 이미 언급했습니다. 또한 개체 그룹(인증서, 요청, CRL)을 선택하고 페이징 모드("선택한 항목 보기..." 버튼)에서 볼 수 있게 되었습니다.

아마도 가장 중요한 것은 프로젝트가 무료로 제공된다는 것입니다. 기타베. Linux용 배포판 외에도 Windows, OS X용 배포판도 준비되어 있으며, Android용 배포판은 잠시 후 공개될 예정입니다.

CAFL63 애플리케이션의 이전 버전과 비교하면 인터페이스 자체가 변경되었을 뿐만 아니라 이미 언급한 것처럼 새로운 기능이 추가되었습니다. 예를 들어, 애플리케이션 설명이 있는 페이지가 다시 디자인되었으며 배포판 다운로드에 대한 직접 링크가 추가되었습니다.

많은 사람들이 GOST openssl을 어디서 구할 수 있는지 묻고 있으며 여전히 묻고 있습니다. 전통적으로 나는 준다. 링크, 친절하게 제공 가렉스. 이 openssl을 사용하는 방법이 작성되었습니다. 여기에.
그러나 이제 배포 키트에는 러시아어 암호화를 사용하는 openssl의 테스트 버전이 포함되어 있습니다.

따라서 CA를 설정할 때 Linux의 경우 /tmp/lirssl_static 또는 Windows의 경우 $::env(TEMP)/lirssl_static.exe를 사용되는 openssl로 지정할 수 있습니다.

이 경우 빈 lirssl.cnf 파일을 만들고 환경 변수 LIRSSL_CONF에 이 파일의 경로를 지정해야 합니다.

인증서 설정의 "확장" 탭에는 CA 루트 인증서 및 OCSP 서버에 대한 액세스 지점을 설정할 수 있는 "기관 정보 액세스" 필드가 추가되었습니다.

CA가 신청자로부터 생성된 요청(PKCS#10)을 수락하지 않거나 더 나쁜 경우 일부 CSP를 통해 이동통신사에서 키 쌍을 생성하여 요청을 강제로 형성한다는 이야기를 자주 듣습니다. 그리고 PKCS#2.0 인터페이스를 통해 검색할 수 없는 키(동일한 RuToken EDS-11)가 있는 토큰에 대한 요청 생성을 거부합니다. 따라서 PKCS#63 토큰의 암호화 메커니즘을 사용하여 CAFL11 애플리케이션의 기능에 요청 생성을 추가하기로 결정했습니다. 토큰 메커니즘을 활성화하기 위해 패키지가 사용되었습니다. TclPKCS11. CA에 대한 요청을 생성할 때("인증서 요청" 페이지, "요청/CSR 생성" 기능) 이제 키 쌍이 생성되는 방법(openssl을 사용하거나 토큰을 사용하여)과 요청 자체가 서명되는 방법을 선택할 수 있습니다.

토큰 작업에 필요한 라이브러리는 인증서 설정에 지정됩니다.

그러나 우리는 회사 VPN 네트워크에서 자체 격리 모드로 작업할 수 있도록 직원에게 인증서를 제공하는 주요 작업에서 벗어났습니다. 일부 직원에게는 토큰이 없는 것으로 나타났습니다. CAFL12 애플리케이션이 이를 허용하므로 PKCS#63 보호 컨테이너를 제공하기로 결정되었습니다. 먼저 그러한 직원에 대해 CIPF 유형 "OpenSSL"을 나타내는 PKCS#10 요청을 한 다음 인증서를 발급하고 이를 PKCS12에 패키지합니다. 이렇게 하려면 "인증서" 페이지에서 원하는 인증서를 선택하고 마우스 오른쪽 버튼을 클릭한 후 "PKCS#12로 내보내기"를 선택합니다.

컨테이너에 모든 것이 제대로 되어 있는지 확인하기 위해 cryptoarmpkcs 유틸리티를 사용해 보겠습니다.

이제 발급된 인증서를 직원에게 보낼 수 있습니다. 어떤 사람들은 단순히 인증서(요청을 보낸 토큰 소유자) 또는 PKCS#12 컨테이너와 함께 파일을 전송받습니다. 두 번째 경우에는 각 직원에게 전화로 컨테이너 비밀번호를 알려줍니다. 이러한 직원은 컨테이너 경로를 올바르게 지정하여 VPN 구성 파일을 수정하기만 하면 됩니다.

토큰 소유자의 경우 토큰에 대한 인증서도 가져와야 했습니다. 이를 위해 동일한 cryptoarmpkcs 유틸리티를 사용했습니다.

이제 VPN 구성이 최소한으로 변경되었으며(토큰의 인증서 레이블이 변경되었을 수 있음) 그게 전부입니다. 회사 VPN 네트워크가 제대로 작동하고 있습니다.

해피 엔딩

그러다가 사람들이 왜 나에게 토큰을 가져오는지, 아니면 내가 그들을 위해 메신저를 보내야 하는지에 대한 생각이 떠올랐습니다. 그리고 다음과 같은 내용의 편지를 보냅니다.

답변은 다음날 옵니다.

즉시 cryptoarmpkcs 유틸리티에 대한 링크를 보냅니다.

인증서 요청을 생성하기 전에 토큰을 지우는 것이 좋습니다.

그런 다음 PKCS#10 형식의 인증서 요청이 이메일로 전송되었으며 인증서를 발급하여 다음 주소로 보냈습니다.

그리고 즐거운 순간이 왔습니다.

그리고 이런 편지도 있었습니다.

그리고 그 이후에 이런 글이 탄생했습니다.

Linux 및 MS Windows 플랫폼용 CAFL63 애플리케이션 배포판을 찾을 수 있습니다.

여기에

• Linux32
• Linux64
• WIN32
• WIN64
• OS X

Android 플랫폼을 포함한 cryptoarmpkcs 유틸리티 배포판은 다음 위치에 있습니다.

여기에

• Linux32
• Linux64
• WIN32
• WIN64
• OS X
• Android

출처 : habr.com