☰

인증서와 두 개의 CA를 사용하여 HTTPd를 통해 사용자를 인증합니다.

tag-icon • tag-icon apache-httpd ssl authentication certificates
인증서와 두 개의 CA를 사용하여 HTTPd를 통해 사용자를 인증합니다.

우리 회사 내부 사이트를 구현하고 가능하면 인증서 인증을 사용하고 싶습니다. 나는 사람들이 모든 것에 대해 자체 서명된 CA를 만드는 다양한 예를 접하고 시도했지만 그것은 내가 원하는 것이 아닙니다.

보안상의 이유로 실제 와일드카드 사이트 인증서를 사용하여 이를 개발하고 싶지 않았습니다. 개인 키 파일이 있는 서버가 적을수록 좋습니다. 내가 하고 싶은 것은 이것이다:

a) 자체 서명된 CA를 사용하여 HTTPS용 SSL 인증서에 서명하고 이를 시스템 인증서 저장소에 추가합니다. 이 모험의 목적에 따라 이것이 첫 번째 CA, 즉 ca-1.

b) S/MIME 인증서를 발급한 CA를 사용하여 인증합니다(그들은예올바른 유형! ) 이 목적(클라이언트 인증)에 사용되는 인증서는 두 번째 CA 또는 에서 발급됩니다 ca-2.

결국 개발이 완료되면 ca-1최종 사용자의 편의와 보안을 위해 a)의 사이트와 인증서를 당사 SSL 인증서 제공업체의 사이트와 인증서로 교체할 예정이나, 개발 사용자 인증을 위해서는 공개 인증서만 사용하기 때문에 실제 인증서를 사용하고자 합니다. 키는 개발 서버에 저장됩니다. 개발 관점에서는 실제 인증서를 사용하는 것이 더 유용합니다.

또한 SSL/TLS 및 인증을 위해 별도의 CA를 선택할 수 있다는 관점에서 이것이 어떻게 수행되는지 보고 싶습니다. (그냥 옛날의 호기심일 뿐이죠.)

내 HTTPd 구성( /etc/httpd/conf.d/site.conf)은 다음과 같습니다.

<VirtualHost *:443>
  ServerName site
  DocumentRoot /srv/site/www
  SSLEngine On
  SSLProtocol all -SSLv2 -SSLv3
  SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5
  SSLHonorCipherOrder On
  SSLCertificateFile /etc/pki/tls/certs/site-1.crt
  SSLCertificateKeyFile /etc/pki/tls/private/site-1.key
  SSLCertificateChainFile /etc/pki/tls/certs/ca-1.crt
  SSLCACertificateFile /etc/pki/tls/certs/ca-2.crt
</VirtualHost>

<Directory /srv/site/www>
  Require all granted
</Directory>

<Directory /srv/site/www/secret>
  SSLVerifyClient require
  SSLVerifyDepth 1
  SSLOptions +StdEnvVars
  SSLVerifyClient require
  Require all granted
</Directory>

<VirtualHost *:80>
  ServerName site
  RewriteEngine On
  RewriteRule ^(/.*)$ https://%{HTTP_HOST}$1 [redirect=301]
</VirtualHost>

또한 SELinux를 사용해야 한다는 것도 알고 있습니다 restorecon -RvF /srv. (이미 그렇게 하고 있습니다.)

아이디어는 인증되지 않은 사용자라도 그래픽을 표시할 수 있도록 열린 스플래시 페이지를 갖는 것입니다(단순히 페이지를 표시하는 대신 재시도하기 전에 컴퓨터에 인증서를 설치하도록 상기시켜 줍니다). 문서 루트의 403 Forbidden콘텐츠 /secret그러나 인증된 사용자에게만 표시됩니다. 스팸 페이지에 있는 소량의 PHP는 /secret의 콘텐츠 가용성을 감지하고 자동으로 사용자를 리디렉션합니다.

계획은 HTTPd가 CA에서 서명한 인증서를 가진 사용자만 인증하도록 하는 것입니다( ca-2.crt이 경우). 그러나 물론 웹 애플리케이션은 인증서의 조직(O)이 우리의 것인지 확인해야 합니다. 나중에 애플리케이션이 CA 및 O(조직)에 만족하면 브라우저가 사용자 인증서에서 공유하는 CN(일반 이름)을 사용하여 이를 인증하며, OU(조직 단위)를 사용하여 권한을 분할할 수도 있습니다. 부서.

많은 아이디어와 마찬가지로 언뜻 보면 어쨌든 좋은 아이디어처럼 보입니다. 그러나 실제로는 원하는 효과를 얻지 못합니다. 브라우저는 이유를 언급 403 Forbidden하지 않은 채 오류 만 표시합니다. 물론 외부 콘텐츠도 잘 작동합니다./var/log/httpd/secret

site-1.crt​내 스마트 카드의 개인 키에 서명한 CA가 될 것입니다. (내 호스트 OS는 이것을 알고 있습니다: 나는 그것을 이메일 서명 및 암호화, SSH를 통해 서버에 로그인하는 데 사용했기 때문에 만족합니다 . ) 제대로 작동하는지 확인하세요. )site-1.keyca-1.crtca-2.crt

또한 모든 사용자의 공개 키를 HTTPd가 인증할 목록에 추가해야 한다는 점을 받아들일 준비가 되어 있습니다. 덜 편리하지만 확실히 안전합니다. 또한 단순히 회사 전체 또는 부서 전체가 리소스에 액세스하도록 허용하는 것이 아니라 보다 세분화된 액세스도 허용합니다.

이 모험에 어떤 도움이라도 주시면 감사하겠습니다.

관련 정보