catpark's something new

AWS 아키텍트

https://aws.amazon.com/ko/certification/certification-prep/

특히 무료 온라인 강의가 있다. Exam Readiness항목에 무료 디지털 교육을 클릭하면 들을 수 있다.

https://aws.amazon.com/ko/training/path-architecting/

Architect과정의 자격증은 associate, professional 두 가지가 있다. 아래 후기에서 처럼 asso는 150달러 pro는 300달러의 응시료가 있다. 그리고 합격 한다면 50% 할인 바우처 1개를 주는데 asso + pro = $150 + ( $300 / 2 ) = $300이고, pro = $300이다. 결과적으로 associate를 따고 pro를 따는 것과 바로 pro를 따는 것은 같은 가격이다. 어떤 path를 선택하던지 개인이 선택하면 될 것 같은데... 나는 시험공부는 길어지는 걸 싫어해서 단기간 집중하려고 한다. 지금까지 프로젝트를 하면서 사용했던 것들도 시험내용과 비교해보고 앞으로 진행할 프로젝트에도 도움이 될 것이라 기대된다.

후기 블로그 : https://goddaehee.tistory.com/194

앞서 인증서를 만들다 보니 CA인증서 밑에 중간 인증서, 중간 인증서 밑에 서버 인증서... 이렇게 상위 하위 인증서 개념이 있었다. 결론부터 보자면

이렇게 server 밑에 sub.server인증서가 있는 것이다. 어떻게 하위 인증서를 만들 수 있을까?

내가 알고 있는 방법은 2가지 방법이다.

1. 상위 key pair (여기선 server를 지칭함.) 하위 key pair(sub.server)를 생성하는 방법
2. 하위 key pair에서 CSR을 발행해서 상위 key pair가 CSR에 sign하는 방법

먼저 상위 key pair(server)에서 바로 key pair를 생성하는 것이다. 

아주 간단하게 필요한 정보만 넣으면 만들어 진다. sub.server키를 export하면 .p12 형식으로 만들어서 전달 가능하다.

다음 방법은 CSR을 사용하여 sub.server키를 만들어 보자. 이 방법은 전 방법과는 다르게 키를 만드는 주체가 서로 다르다는 것이다. 서로 다른 서버에서 각각 키를 만들었는데 어떻게 sign을 하는지가 포인트다.

서로 다른 JKS 키가 있다. 각각 key pair를 살펴보면 아래와 같이 전혀 상관없는 key pair이다.

이 상태에서 sub.server키에서 CSR을 생성한다. p10형식의 .csr파일이 생성된다.

이제 만들어진 CSR 파일로 server키에서 sign을 하면 된다.

CSR에 대한 응답으로 .p7r파일이 생성된다.

sub.server키에서 import CA reply를 한 결과 위와 같이 설정된다.

캡처가 장황하게 들어가서 길어졌지만 CSR을 간단하게 설명하면 sub키에서 CSR을 생성하면 server키에서 .p7r로 sign을 하고 다시 sub키에서 .p7r를 import 하면 된다.

openssl script로 뭐가 뭐지? 하며 정리가 안되던 차에 keystore explorer로 눈에 보이게 캡처를 하나하나 떠서 만들어 정리해봤다. 혹시라도 헷갈리시는 분은 이렇게 정리하고 script를 다시 보면 이해가 가지 않을까 싶다.

지금 운영되는 서버에 인증서가 만료가 되었다. 서로 다른 도메인의 서버끼리 2way 인증을 하는데는 서로의 certification을 가지고 있어야 한다. Java Key Store는 key pair와 trusted certificate를 담을 수 있는 그릇이다.

먼저 갱신한 인증서를 확인해보자. 

서버쪽은 CA인증서로부터 발급받은 key pair이고, 클라이언트는 self-signed key pair이다. 이 상태로는 2way ssl 인증이 안된다. 서로의 certification을 교환해서 가지고 있어야 된다.

x.509형식의 .cer파일을 클라이언트 JKS에 import하자.

마지막 그림처럼 Trusted Certificate로 server의 certificate가 추가 되었다.

그럼 반대로 클라이언트 인증서를 서버 JKS에 추가하는 것도 같은 방식으로 진행하면 된다.

.cer 파일로 추출된 클라이언트 인증서를 서버JKS에 trusted 인증서로 등록하자.

이제 서버에서 JKS 관련 설정을 해보자. application.yml에서 아래와 같이 설정한다.

설정 키 값만 보더라도 뭘 의미 하는지는 알 수 있을거라 믿는다. 이 설정 중에 주목해야 할 것이 하나 있는데 바로 server.ssl.client-auth : need 항목이다. 이 설정이 있어야 약속된 인증서(Trusted Certificate)를 들고 접속하는 클라이언트인지 아닌지 체크를 하게 되어있다. 역시 spring boot... 설정만으로 mutual ssl 인증이 동작하는 구나...

참고 사이트 : https://www.naschenweng.info/2018/02/01/java-mutual-ssl-authentication-2-way-ssl-authentication/

openssl을 이용한 script에 대한 내용은 많아서 Keystore Explorer를 이용하여 캡쳐를 만들어 보았다. 하지만 개인적으로는 (git 사용도 마찬가지로) GUI보다 CLI가 더 안정적이고 풍부한 기능을 제공하니 되도록 CLI를 사용하는 버릇을 들이는게 좋을 듯 하다.