728x90

개요
 리버스프록시 요청 시 통신이 잘되던 도메인에서 특정 시점 이후로 통신이 되지 않음.

현상
  특정 시점 이후로 리버스프록시를 통한 통신 불가.(HTTP 503 발생)
  일반 브라우저에서는 해당 도메인 통신 정상 작동.

원인
 WEBTOB는 요청되는 타겟의 도메인 정보를 컴파일 시 해당시점의 정보로 저장.
 따라서 도메인의 IP가 유동적일 경우 IP가 바뀐 시점 부터는 WEBTOB를 통한 리버스프록시 불가.

해결방안
WEBTOB 설정 변경을 통해 해결 가능
 따라서 다음과 같이 설정

*REVERSE_PROXY
Options="DynamicServerAddress" 적용

> 타겟과 연결 실패시 DNS resolution을 다시 시도한다.

728x90
728x90

웹서비스를 운영하다 보면 SSL인증서를 접하게 된다.

개념 참고
https://yozm.wishket.com/magazine/detail/1852/

그에 필요한 사항들을 정리 해본다.

1. SSL 연결 확인
$ openssl s_client -connect [IP:PORT] -cipher "ECDHE-RSA-AES128-SHA256"

2. SSL 인증서 시작일과 만료일 확인
$ openssl s_client -connect [IP:PORT] | openssl x509 -dates
$ openssl x509 -in cerfile.cer -noout -text

● jks인증서 일 시
$ ${JAVA_HOME}/bin/keytool -list -keystore [인증서파일] -v

3. p12 인증서 정보 확인법(푸시 인증서)
$ openssl pkcs12 -in apple.p12 -out cert.pem -nodes
$ cat cert.pem | openssl x509 -noout -text

※WEBTOB를 사용시 wbssl 명령어로 대체 가능

4. SSL 인증서 브라우져 체크 무시
브라우저(internet explorer)에서 CA와 통신이 되지 않을때 브라우저는 사용자에게 경고창을 띄우게 된다.
해당 경고창을 보고 싶지 않을때 사용
"인터넷 옵션 - 고급"
[서버의 인증서 해지 확인], [인증서 주소가 일치하지 않은 경우에 경고] 체크 해지 후 브라우저 재시작

5. SSL 인증서와 키값의 쌍이 맞는지 보는법
SSL인증서 파일과 각각의 서버에서 보유하고 있는 개인키 파일의 CN(Common Name) 일치여부 확인
openssl rsa -in default.key -modulus -noout | openssl md5
openssl x509 -in default.crt -modulus -noout | openssl md5

■ apahe ssl설정과 csr
출처 : https://www.comodossl.co.kr/certificate/ssl-installation-guides/Apache-csr-crt.aspx

728x90
728x90
문자 집합(Character Set)과 인코딩(Encoding)
  문자 집합은 정보를 표현하기 위한 글자나 기호들의 집합을 정의한 것.
  문자나 기호를 컴퓨터에서 저장하거나 통신에 사용할 목적으로 부호화 하는 것을 문자 인코딩이라 하고 인코딩 된 문자 부호를 다시 본래 문자나 기호로 표현하는 것을 복호화(디코딩)이라고 함.

한글문자의 인코딩
  EUC-KR : 2바이트 완성형 인코딩 방식으로 완성된 음절을 코드와 일대일 대응시키는 방식 
    EX) '가' 0xB0A1, '각' 0xB0A2
    
  유니코드 (UTF-7, UTF-8): 하나의 인코딩을 통해 여러가지 문자 집합을 표현할 수 있도록 고안되었으며, 여러가지 유니코드 중 ASCII와 호환이 가능하면서 한글을 표현할 수 있는 UTF-8을 가장 많이 사용.
    ※UTF-8 경우 3바이트로 표현됨

OS Locale
  OS 상에서는 국가와 언어에 따라 다양한 OS Locale을 제공
  Locale에 따라서 입/출력 인코딩을 적용해서 메시지를 출력
    EX) 언어_국가.코드셋 language[_territory][.codeset]
        ko_KR.utf8

  locale 명령으로 시스템의 locale 정보 확인 가능
    LANG - LC_* 값들을 설정하지 않았을 때 적용되는 기본 값
    LC_ALL - LC_* 값으로 override 됨
    LC_TIME - 시간 출력 양식 설정
    LC_NUMBER - 숫자표현양식
    LC_NAME - 이름 표기 형식
    LC_MESSAGES - 시스템 메시지 출력에 사용할 언어
    LC_CTYPE - 바이트를 문자로 변환하거나, 대문자/소문자간의 변환 형식

  java에서는 파일과 소켓등으로 문자열 IO처리시, 문자열의 default charset은 OS Locale 값을 따름.
  default charset은 jvm 옵션 "-Dfile.encoding" 설정을 통해 OS Locale과 다르게 설정 가능.
  
  file.encoding은 파일이나 소켓 등으로 문자열 IO처리 시, 특정 API의 기본값으로 사용.
    System.out.print()는 file.encoding의 영향을 받는다. 
    Out.print()는 response encoding의 영향을 받는다.
    charset을 지정하지 않은 html 또는 jsp 파일은 해당파일을 저장할 때의 인코딩으로 브라우져가 알아서 디코딩 한다.

파일과 인코딩
  한글 파일명의 인코딩
    파일의 이름이 어떤 인코딩으로 서버에 저장되고, 어떤 인코딩으로 다운로드가 되는지는 해당 action을 수행하는 tool에 의해 결정.
      동일한 인코딩으로 업로드와 다운로드를 하지 않는 다면 한글이 깨지게 됨.
  
  파일 내용의 한글 인코딩
    파일 내용의 인코딩은 파일을 최초 생성하여 저장할 때 결정.
      windows의 경우 에디터 및 프로그램에서 원하는 인코딩값으로 저장가능
      Unix 및 Linux에서는 iconv 명령어로 파일내용의 인코딩을 변경 가능
        UTF-8 -> EUC-KR : iconv -c -f utf8 -t euckr utf8.txt > euckr.txt
        EUC-KR -> UTF-8 : iconv -c -f euckr -t utf8 euckr.txt > utf8.txt
    저장된 한글내용을 읽어들일 때 아래와 같은 2가지 경우가 발생
      1. memory에 로딩하는 경우 (file.encoding과 연관)
      2. memory에 로드 하지않고 response로 전달해주는 경우 (response encoding과 연관)

  한글 파일명 업로드
    1. 파일객체를 request 객체를 통해 전달 (전달 시 form을 생성하는 jsp 또는 html의 response encoding으로 전달)
    2. Server의 application 로직에 따른 특정 encoding으로 읽어들여 ememory에 로딩
    3. memory에 로딩된 data를 WAS가 기동 된 OS Locale에 기반하여 파일 생성
   
728x90

+ Recent posts