PROVIDER

1. InvalidProviderToken

1-1. 참고

  • APNS 프로토콜이 HTTP2 방식인 경우 발생한다.

1-2. 원인

  • 올바른 team ID 와 key ID가 아닌 경우

  • 개발자 사이트에서 발급된 p8인증서가 삭제되어 있는 경우

1-3. 확인필요사항

아래의 예제와 같이 Provider 설치 시

고객사에서 생성한 APNS인증서를 서버에 업로드하고,

고객사에서 제공한 team ID 와 key ID를 설정하는 부분이 있습니다.

  • config.properties

APNS_HTTP2_TOKEN_SRC1 = /home/push/provider/conf/AuthKey_5P9LQ3VVSU.p8

APNS_HTTP2_TEAMKEY1 = GZ4R68N79W

APNS_HTTP2_KEYID1 = 5P9LQ3VVSU

제공된 team ID 와 key ID가 올바르게 제공이 되었는지 확인 필요합니다.

2. BadDeviceToken

2-1. 참고

  • APNS 프로토콜이 HTTP2 방식인 경우 발생한다.

2-2. 원인

  • 서버에 등록된 개발/상용 구분 정보(APNS_MODE)와 iOS App 빌드 환경이 다른 경우

  • Xcode11 + iOS13 버전 이슈

2-3. 확인필요사항(1)

IOS의 경우 빌드를 할때 개발용 인증서(development)를 사용하여 빌드할 경우에는 개발용 토큰값이 발급이 되고, 상용 인증서(distribution)를 사용하여 빌드를 할 경우에는 상용용 토큰값이 발급이 됩니다.

상용용 토큰값은 서비스등록을 할때 APNS_MODE 가 REAL 이어야 정상 동작 하고, 개발용 토큰값은 서비스등록을 할때 APNS_MODE 가 DEV이어야 정상동작합니다.

registerService 또는 registerServiceAndUser 를 호출할때 파라메터로 올라가는 APNS_MODE 값이 REAL 인지 DEV 인지 체크 하시면 됩니다.

해당 값이 REAL일 경우 상용 APNS서버로 메시지를 발송하고 DEV일 경우 개발 APNS서버로 메시지를 발송합니다.

APNS토큰값은 빌드할때 개발자 인증서에 따라 개발용 토큰값과 상용용 토큰값이 구분되어 발급되오니 해당 빌드 환경에 맞춰 REAL, DEV 셋팅후 테스트를 진행하시면 됩니다.

APNS_MODE값을 변경하는 부분은 PushReceiver.m 파일에 아래 부분을 추가해주시면 됩니다. (기본값은 REAL입니다. 추가하지 않으면 REAL 입니다.)

[[PushManager defaultManager].info changeMode:@”DEV”];

BadDeviceToken은 토큰값과 APNS서버 상용, 개발값이 일치하지 않을때 주로 발생하는 부분으로 APNS_MODE값과 개발환경을 확인바랍니다.

2-4. 확인필요사항(2)

Xcode11 + iOS13 버전의 경우에서도 BaddeviceToken 이슈가 있을 수 있습니다.

IOS 13에서 부터는 APNS TOKEN 값의 포멧이 변경 되었습니다.

  • 기존 포맷 (ios 12 이하): b955bd26 a346e0c2 1dbd8487 7e50ca09 376772c6 e2facee3 e7b39cf8 a9861eec

  • 변경 포멧 (iOS 13 이상): {length = 32, bytes = 0x7c6c914a b13e408f 3ecab22b 5705e940 … ae2736fd 5c07a408 }

Case

결론

Xcode10 이하 버전에서 배포한 앱 + 기존 Push 라이브러리 (5.0.2이하)

iOS13단말기에서 정상 동작

Xcode11 이상 버전에서 배포한 앱 + 기존 Push 라이브러리 (5.0.2이하)

iOS13단말기에서 오동작

Xcode11 이상 버전에서 배포한 앱 + 최신 Push 라이브러리 (5.0.3이상)

iOS13이하 단말기에서 정상 동작

Xcode11 이상 버전에서 배포한 앱 + 최신 Push 라이브러리 (5.0.3이상)

iOS13단말기에서 정상 동작

Xcode 11 이상에서 앱을 배포시에는 반드시, 최신 Push 라이브러리(5.0.3이상) 버전을 사용바랍니다.

3. INVALID_TOKEN

3-1. 참고

  • APNS 프로토콜이 BINARY 방식인 경우 발생한다.

3-1. 원인

  • 2-2 와 동일

  • 또는 인증서를 생성하는 Macbook의 JDK환경과 서버의 JDK 환경이 상이한 경우

3-2. 확인필요사항(1)

  • 2-3, 2-4 참고

3-3. 확인필요사항(2)

provider에 등록된 APNS 인증서(확장자 p12) jdk 변환 방법

  • 1.6에서 jks 생성 (JDK경로는 고객사마다 다릅니다.)

    ${JAVA1.6_HOME}/bin/keytool -importkeystore -destkeystore <변환파일> -srckeystore <인증서파일> -srcstoretype PKCS12

    예) ~/JAVA/jdk1.6.0_24/bin/keytool -importkeystore -destkeystore Push_Distribution.jks -srckeystore Push_Distribution.p12 -srcstoretype PKCS12

  • 1.7에서 jks를 이용 p12 생성 (JDK경로는 고객사마다 다릅니다.)

    ${JAVA1.7_HOME}/bin/keytool -importkeystore -srckeystore <변환파일> -srcstoretype JKS -deststoretype PKCS12 -destkeystore <인증서파일>

    예) ~/JAVA/jdk1.7.0_80/bin/keytool -importkeystore -srckeystore Push_Distribution.jks -srcstoretype JKS -deststoretype PKCS12 -destkeystore Push_Distribution.p12

해당 과정으로 변환된 인증서를 서버에 업로드 이후 Provider 재기동하여 동일한 오류가 있는지 확인 필요

4. Received fatal alert: certificate_expired

4-1. 참고

  • APNS 프로토콜이 BINARY 방식인 경우 발생한다.

4-2. 발생오류

javax.net.ssl.SSLHandshakeException: Received fatal alert: certificate_expired

4-2. 원인

  • 실제 개발자 사이트에 등록된 인증서와 provider 에 등록된 APNS 인증서(확장자 p12)가 상이한 경우

  • provider에 등록된 APNS 인증서(확장자 p12)의 기간이 만료된 경우

  • 위 2가지 경우가 아닌 경우 - 인증서를 생성하는 Macbook의 JDK환경과 서버의 JDK 환경이 상이한 경우

4-3. 확인필요사항(1)

provider에 등록된 APNS 인증서(확장자 p12)의 기간 확인 방법

  • openssl을 이용한 pkcs12 형식의 인증서를 x509 인증서로 변환

  • 인증서 패스워드를 입력하라고 나옴. 패스워드를 알고 있어야 함

    openssl pkcs12 -in <인증서파일> -out <변환파일> -nodes -clcerts

    예) openssl pkcs12 -in Push_Distribution.p12 -out Push_Distribution.pem -nodes -clcerts

  • x509 인증서에서 만료일 정보 반환

    openssl x509 -in <변환된파일> -noout -enddate

    예) openssl x509 -in Push_Distribution.pem -noout -enddate

4-4. 확인필요사항(2)

  • 3-3 참고

5. Given final block not properly padded

5-1. 참고

  • APNS 프로토콜이 BINARY 방식인 경우 발생한다.

5-2. 발생오류

java.io.IOException: failed to decrypt safe contents entry: javax.crypto.BadPaddingException: Given final block not properly padded

5-2. 원인

  • provider에 등록된 APNS 인증서(확장자 p12)의 패스워드가 틀린 경우

  • provider 설정파일인 config.properties 파일의 패스워드 설정이 실제 패스워드와 다른 경우

5-3. 확인필요사항

image1

  • 설치되어 있는 Provider 홈 디렉터리의 conf/config.properties 파일에 위 이미지와 같은 설정이 있습니다.
    • 설정되어 있는 패스워드가 실제 인증서 패스워드와 동일한지 확인 필요

    • 패스워드 설정의 마지막에 공백이 있는지 확인 필요

  • conf/config.properties 파일이 수정되는 경우 provider 재기동이 필요합니다.