어려운 작업을하기 위해 Linux에는 인증서 작업을위한 라이브러리가 둘 이상 있습니다.
당신이 모질라의 NSS를 사용하는 경우, 당신이 할 수있는 적극적 불신 (그들의 용어)를 사용하여 인증서 의 certutil을 들에게 ' -t trustargs
옵션 :
$ certutil -d <path to directory containing database> -M -t p -n "Blue Coat Public Services Intermediate CA"
파이어 폭스의 경우, <path to directory containing database>
일반적으로 ~/.mozilla/firefox/<???>.profile
어디에 <???>
어떤 임의의보고 문자가 있습니다. (certutil은 예를 들어 우분투의 libnss3-tools 패키지에 있습니다)
고장은 다음과 같습니다.
-M
데이터베이스를 수정
-t p
신뢰를 금지로 설정
-n
명명 된 인증서에 대한 작업 수행
NSS 내에서도 모든 응용 프로그램이 동일한 데이터베이스를 공유하는 것은 아닙니다. 이 과정을 반복해야 할 수도 있습니다. 예를 들어, 변경, 크롬에 대해 동일한 작업을 수행하기 -d <path>
에 -d sql:.pki/nssdb/
.
$ certutil -d sql:.pki/nssdb/ -M -t p -n "Blue Coat Public Services Intermediate CA"
그러나 모든 응용 프로그램이 NSS를 사용하는 것은 아니므로 완벽한 솔루션은 아닙니다. 예를 들어 OpenSSL 라이브러리 로이 작업을 수행 할 수 있다고 생각하지 않습니다.
결과적으로 인증서 체인 빌딩 (TLS, IPSec 등)을 제공하기 위해 OpenSSL을 사용하는 모든 응용 프로그램은 Blue Coat 인증서가있는 체인을 신뢰하며 서명 한 루트 CA를 제거하는 것 외에는 할 수있는 일이 없습니다. NSS에 의존하는 응용 프로그램은 내부에 Blue Coat 인증서가있는 체인을 신뢰할 수 없도록보다 세밀하게 구성 할 수있는 반면, 트러스트 앵커 저장소 (인터넷의 절반을 신뢰하지 않을 경우 Symantec Root CA라고 생각하는 것은 어리 석음) .
예를 들어 OpenVPN은 인증서 라이브러리로 OpenSSL을 사용한다고 생각하므로 OpenVPN을 사용하는 상용 VPN 제공 업체에 연결하는 경우 빅 브라더가 사용자 모르게 OpenVPN 트래픽을 수신 할 수 있습니다. 정말로 염려되는 경우 상용 VPN 제공 업체의 루트 CA가 누구인지 확인하십시오. Symantec / Verisign 인 경우 다른 사람을 위해 도랑을 파야 할 때입니까?
SSH는 X509 인증서를 사용하지 않으므로 Blue Coat MITM 공격에 대한 걱정없이 SSH를 사용하여 연결하고 터널링 할 수 있습니다.