NGINX는 SSL 양방향 인증을 구성합니다.
- 高洛峰원래의
- 2016-11-17 13:21:581893검색
배경
NGINX의 HTTPS 구성의 경우 일반적으로 브라우저에 신뢰할 수 있는 인증 기관(CA)이 내장되어 있고 서버 측에서는 서버 측 인증만 구현하면 됩니다. 이러한 조직에서 발급한 인증서를 구성한 후 브라우저는 인증서 자체의 유효성을 확인하고 SSL을 통해 통신을 암호화합니다.
그러나 특별한 경우에도 클라이언트를 확인해야 합니다. 신뢰할 수 있는 클라이언트만 서비스 인터페이스를 사용할 수 있습니다. 이때 이 목적을 달성하려면 클라이언트가 요청할 때만 사용할 수 있습니다. 인증서를 사용하여 서버 인터페이스를 조정할 수 있습니다.
CA 및 자체 서명
CA는 권위 있는 기관에서만 수행할 수 있으며 해당 기관이 보안 표준을 충족하지 못하면 얼마 전까지만 해도 브라우저 제조업체에 의해 "금지"됩니다. , WoSign 및 StartSSL Mozilla 및 Chrome에 의해 차단되었습니다. 그러나 우리는 자체 CA를 구축하기 때문에 양방향 인증 구성에는 영향을 미치지 않습니다.
편의를 위해 NGINX 디렉터리에 인증서 관련 생성을 만듭니다:
cd /etc/nginx mkdir sslcd ssl
CA 개인 키 만들기
openssl genrsa -out ca.key 2048
CA 루트 인증서 만들기(공개 키)
openssl req -new -x509 -days 3650 -key ca.key -out ca.crt
참고:
일반 이름은 원하는 대로 입력할 수 있습니다
기타 실수 방지를 위해 필수 사항을 모두 입력해주세요.
서버측 인증서
서버측 개인키 만들기
openssl genrsa -out server.pem 1024 openssl rsa -in server.pem -out server.key
서명 요청 생성
openssl req -new -key server.pem -out server.csr
참고:
서비스에 액세스할 때 일반 이름을 도메인 이름으로 입력해야 합니다. 여기서는 다음 NGINX 구성을 사용합니다.
실수 방지를 위해 입력해야 하는 기타 정보를 사용합니다. (CA 루트 인증서와 일치하도록)
CA에서 발급
openssl x509 - req -sha256 -in server.csr -CA ca.crt -CAkey ca.key - CAcreateserial -days 3650 -out server.crt
클라이언트 인증서
는 서버와 유사합니다. 인증서:
참고:
일반 이름은 괜찮습니다.
기타 입력해야 할 정보는 실수를 방지하기 위해 . CA 루트 인증서와 일치하도록)
이제 필요한 인증서가 준비되었으므로 NGINX 구성을 시작할 수 있습니다.
NGINX
server {
listen 443 ssl;
server_name usb.dev;
access_log off;
ssl on;
ssl_certificate /etc/nginx/ssl/server.crt;
ssl_certificate_key /etc/nginx/ssl/server.key;
ssl_client_certificate /etc/nginx/ssl/ca.crt;
ssl_verify_client on;
location / {
proxy_pass http://backend$request_uri;
}
}여기서 ssl_client_certificate /etc/nginx/ssl/ca.crt는 CA 인증서를 사용하여 요청의 클라이언트 인증서가 CA에서 발급되었는지 확인하는 것을 의미합니다.
구성 후 NGINX를 다시 로드합니다.
service nginx reload
자, 이제 검증을 시작할 수 있습니다.
확인 요청
확인 프로세스는 다른 컴퓨터나 이 컴퓨터에서 수행할 수 있습니다. usb.dev를 구문 분석하려면 /etc/hosts도 구성해야 합니다.
127.0.0.1 usb.dev
브라우저 확인을 사용하는 경우 클라이언트 인증서를 p12 형식으로 내보내야 하며 여기서는 건너뜁니다. 우리의 초점은 컬을 통한 확인에 있습니다.
curl --insecure --key client.key --cert client.crt 'https://usb.dev'
여기서 --insecure는 자체 구축 CA의 비권한 특성을 무시하는 것입니다. 확인이 정상이라면 운이 좋을 것입니다. 여기에 깊은 구덩이가 있기 때문입니다. 일부 버전의 컬은 오류를 보고합니다.
<html> <head><title>400 No required SSL certificate was sent</title></head> <body bgcolor="white"> <center><h1>400 Bad Request</h1></center> <center>No required SSL certificate was sent</center> <hr><center>nginx/1.11.0</center> </body> </html>
이러한 오류 보고 버전의 컬은 실제로 경로에 대한 엄격한 요구 사항을 갖습니다. --cert 실제 매개변수는 완전히 정확해야 합니다. 예를 들어 현재 디렉터리에서 --cert ./client.crt를 사용해야 합니다. --cert client.crt를 사용하는 것은 잘못되었습니다. 피트 등반 과정에서 전체 과정을 관찰하기 위해 -v 매개변수가 활성화되었으며 경보가 발견되었습니다.
warning: certificate file name "client.crt" handled as nickname; please use "./client.crt" to force file name