- 문제: 신뢰할 수 없는 CA 또는 자체 서명된 인증서 사용
수정: Webhook 콜백 서버에 대한 공개 CA 발급 SSL 인증서를 사용합니다.
마지막 업데이트 날짜
2023년 11월 15일
새로운 기능
시작하기
관리
- Admin Console 개요
- 사용자 관리
- 사용자 추가
- 기능 중심 사용자 생성
- 프로비저닝 오류가 있는 사용자 확인
- 이름/이메일 주소 변경
- 사용자의 그룹 멤버십 편집
- 그룹 인터페이스를 통해 사용자의 그룹 멤버십 편집
- 사용자를 관리자 역할로 승격
- 사용자 ID 유형 및 SSO
- 사용자 ID 전환
- MS Azure로 사용자 인증
- Google Federation으로 사용자 인증
- 제품 프로필
- 로그인 경험
- 계정/그룹 설정
- 설정 개요
- 전역 설정
- 계정 계층 및 ID
- 새로운 수신자 환경
- [자체 서명] 워크플로우
- 대량 전송
- 웹 양식
- 사용자 지정 전송 워크플로우
- Power Automate 워크플로우
- 라이브러리 문서
- 계약서를 사용하여 양식 데이터 수집
- 제한된 문서 표시 여부
- 서명된 계약의 PDF 사본 첨부
- 이메일에 링크 포함
- 이메일에 이미지 포함
- 이메일에 첨부된 파일의 이름 지정
- 문서에 감사 보고서 첨부
- 여러 문서를 하나로 병합
- 개별 문서 다운로드
- 서명된 문서 업로드
- 내 계정의 사용자에 대한 위임
- 외부 수신자의 위임 허용
- 서명 권한
- 전송 권한
- 전자 봉인 추가 권한
- 기본 시간대 설정
- 기본 날짜 형식 설정
- 다중 그룹의 사용자(UMG)
- 그룹 관리자 권한
- 수신자 바꾸기
- 감사 보고서
- 트랜잭션 꼬리말
- 제품 내 메시지 및 지침
- 액세스할 수 있는 PDF
- 새로운 작성 환경
- 의료 고객
- 계정 설정
- 로고 추가
- 회사 호스트 이름/URL 사용자 지정
- 회사 이름 추가
- 계약 후 URL 리디렉션
- 서명 기본 설정
- 서식이 올바르게 지정된 서명
- 수신자의 서명 허용
- 서명자 이름 변경 가능
- 수신자가 자신이 저장한 서명을 사용하도록 허용
- 사용자 지정 사용 약관 및 소비자 공개
- 폼 필드를 통해 수신자 탐색
- 계약 워크플로우 다시 시작
- 서명 거부
- 스탬프 워크플로우 허용
- 서명자에게 직책 또는 회사 제공 요청
- 서명자의 자필 서명 인쇄 및 배치 허용
- 전자 서명 시 메시지 표시
- 서명자가 모바일 장치를 사용하여 서명을 작성하도록 요청
- 서명자의 IP 주소 요청
- 참여 스탬프에서 회사 이름 및 직책 제외
- 디지털 서명
- 전자 봉인
- 디지털 신원
- 보고서 설정
- 새로운 보고서 환경
- 기존 보고서 설정
- 보안 설정
- 전송 설정
- 로그인 후 전송 페이지 표시
- 전송 시 수신자 이름 필요
- 알려진 사용자에 대한 이름 값 잠금
- 허용된 수신자 역할
- 전자 증명자 허용
- 수신자 그룹
- CC
- 수신자 계약 액세스
- 필수 필드
- 문서 첨부
- 필드 결합
- 계약 수정
- 계약 이름
- 언어
- 개인 메시지
- 허용되는 서명 유형
- 알림 메시지
- 서명된 문서 암호 보호
- 다음을 통해 계약 알림 전송
- 서명자 식별 옵션
- 콘텐츠 보호
- Notarize 트랜잭션 활성화
- 문서 만료
- 서명 미리 보기, 배치 및 필드 추가
- 서명 순서
- Liquid Mode
- 사용자 지정 워크플로우 제어
- 전자 서명 페이지 업로드 옵션
- 서명 후 확인 URL 리디렉션
- 메시지 템플릿
- Bio-Pharma 설정
- 워크플로우 통합
- 공증 설정
- 결제 통합
- 서명자 메시징
- SAML 설정
- SAML 구성
- Microsoft Active Directory Federation 서비스 설치
- Okta 설치
- OneLogin 설치
- Oracle Identity Federation 설치
- SAML 구성
- 데이터 거버넌스
- 타임 스탬프 설정
- 외부 보관
- 계정 언어
- 이메일 설정
- echosign.com에서 adobesign.com으로 마이그레이션합니다.
- 수신자 옵션 구성
- 규정 요구 사항 지침
- 계약서 일괄 다운로드
- 도메인 요청
- 오용 신고 링크
계약 전송, 서명 및 관리
- 수신자 옵션
- 계약 보내기
- 문서에 필드 작성
- 인앱 작성 환경
- 텍스트 태그로 폼 만들기
- Acrobat으로 폼 만들기(AcroForm)
- 필드
- 작성 FAQ
- 계약 서명
- 계약 관리
- 감사 보고서
- 보고 및 데이터 내보내기
고급 계약 기능 및 워크플로우
- 웹 양식
- 재사용 가능 템플릿(라이브러리 템플릿)
- 웹 양식 및 라이브러리 템플릿의 소유권 이전
- Power Automate 워크플로우
- Power Automate 통합 및 포함된 권한 개요
- Power Automate 통합 활성화
- 관리 페이지의 컨텍스트별 작업
- Power Automate 사용 추적
- 새 플로우 만들기(예시)
- 플로우에 사용되는 트리거
- Acrobat Sign 외부에서 플로우 가져오기
- 플로우 관리
- 플로우 편집
- 플로우 공유
- 플로우 비활성화 또는 활성화
- 플로우 삭제
- 템플릿 사용
- 관리자만
- 계약 보관
- 웹 양식 계약 보관
- 작성한 웹 양식 문서를 SharePoint 라이브러리에 저장
- 작성한 웹 양식 문서를 OneDrive for Business에 저장
- 작성한 문서를 Google Drive에 저장
- 작성한 웹 양식 문서를 Box에 저장
- 계약 데이터 추출
- 계약 알림
- 계약 콘텐츠 및 서명된 계약서와 함께 사용자 지정 이메일 알림 전송
- Teams 채널에서 Adobe Acrobat Sign 알림 받기
- Slack에서 Adobe Acrobat Sign 알림 받기
- Webex에서 Adobe Acrobat Sign 알림 받기
- 계약 생성
- Power App 양식 및 Word 템플릿에서 문서를 생성하고 서명을 위해 전송
- OneDrive의 Word 템플릿에서 계약 생성 및 서명 받기
- 선택한 Excel 행에 대한 계약 생성, 검토를 위해 보내기 및 서명
- 사용자 지정 전송 워크플로우
- 사용자 및 계약 공유
다른 제품과 통합
- Acrobat Sign 통합 개요
- Salesforce용 Acrobat Sign
- Microsoft용 Acrobat Sign
- 기타 통합
- 파트너 관리 통합
- 통합 키 획득 방법
Acrobat Sign 개발자
- REST API
- Webhook
지원 및 문제 해결
양방향 SSL 인증
클라이언트측 SSL 또는 상호 TLS라고도 하는 양방향 SSL은 서버 및 클라이언트(웹 브라우저)가 모두 자신을 식별하기 위한 인증서를 제공하는 SSL 모드입니다.
계정 관리자는 보안 설정 페이지에서 클라이언트측 인증서를 구성할 수 있습니다.
Acrobat Sign은 페이로드를 Webhook URL로 전달할 때 SSL 인증서를 확인합니다. SSL 인증서 확인에 실패한 Webhook은 JSON 페이로드를 성공적으로 전달하지 않습니다.
양방향 SSL을 사용하여 클라이언트(Acrobat Sign) 및 수신 대기 서비스를 인증하면 Acrobat Sign만 Webhook URL에 연결할 수 있습니다.
파트너 애플리케이션에 의해 생성된 Webhook은 Webhook 알림을 전송할 때 파트너 애플리케이션 계정의 클라이언트 인증서(사용 가능한 경우)를 사용하여 자체 식별합니다.
다음은 웹 서버 확인 프로세스와 클라이언트 인증 확인에 대한 가장 일반적인 질문입니다.
웹 서버 확인
Webhook을 등록하는 동안 Acrobat Sign은 Webhook 서버 URL을 확인합니다.
Acrobat Sign에서 Webhook 콜백 URL에 대한 연결을 완료할 수 없는 경우 고객은 Webhook를 등록할 수 없습니다.
아니요.
Webhook 콜백 URL은 포트 443 또는 8443의 HTTPS만 가능합니다.
Acrobat Sign은 모든 다른 포트로 가는 아웃바운드 HTTPS 트래픽을 차단합니다.
서버 인증서를 확인하는 좋은 방법은 DigiCert® SSL 설치 진단 도구를 사용하는 것입니다.
호스트 이름만 입력합니다. 예: www.digicert.com
일반적인 문제는 다음과 같습니다.
- 문제: 서버가 중간 인증서를 보내지 않습니다.
수정: Webhook 콜백 서버에 중간 인증서를 설치합니다.
자세한 내용은 https://www.digicert.com/kb/ssl-certificate-installation.htm을 참조하십시오.
클라이언트 인증서 확인
Webhook에 대해 양방향 SSL을 설정하려면 관리자가 개인 키가 포함된 .p12(또는 .pfx) 파일을 업로드해야 합니다. 파일은 고객 계정 내에 안전하게 저장되며 관리자가 언제든 제거할 수 있는 모든 권한을 갖습니다.
양방향 Webhook 설정에서, Acrobat Sign은 발신자/클라이언트이며, 고객 계정을 대신하여 Acrobat Sign이 호출하는 것임을 증명하기 위해 개인 키가 필요합니다.
-
양방향 SSL이 활성화되었는지 확인
Webhook 콜백 서버에 양방향 SSL이 활성화되어야 합니다.
웹 브라우저를 사용하여 Webhook 콜백 URL에 연결합니다. 다음 메시지가 표시됩니다.
400 잘못된 요청 필수 SSL 인증서가 전송되지 않았습니다.
즉, 서버는 클라이언트가 클라이언트 인증서를 보낼 것으로 예상한다는 뜻입니다(양방향 SSL이 서버에 대해 활성화됨).
위의 메시지가 표시되지 않으면 양방향 SSL이 활성화되지 않은 것입니다.
참고:Postman을 사용하여 Webhook 콜백 URL에 대한 POST 요청을 수행할 수 있습니다. 비슷한 결과를 얻게 됩니다.
-
클라이언트 자격 증명은 자체 서명된 인증서 또는 CA 발급 인증서일 수 있습니다. 단, 최소한 다음 X.509 v3 확장을 준수해야 합니다.
X.509 v3 확장
값
ExtendedKeyUsage
clientAuth(OID: 1.3.6.1.5.5.7.3.2)
KeyUsage
digitalSignature
클라이언트 인증서는 확장명이 .p12 또는 .pfx인 PKCS12 파일이어야 하며 클라이언트 인증서(서버가 클라이언트의 신원을 확인할 수 있도록)와 클라이언트의 개인 키(클라이언트가 SSL 핸드셰이크 중에 서버가 확인할 메시지에 디지털 서명할 수 있도록)를 모두 포함해야 합니다.
openssl 명령을 사용하여 p12(pfx) 파일을 확인:
openssl pkcs12 -info -in outfile.p12
개인 키의 암호를 요청해야 합니다. 출력에는 다음과 같이 두 인증서와 암호화된 개인 키가 모두 포함되어야 합니다.
Bag Attributes localKeyID: 9D BD 22 80 E7 B2 B7 58 9E AE C8 42 71 F0 39 E1 E7 2B 57 DB subject=/C=US/ST=California/L=San Jose/O=Adobe Inc./CN=sp.adobesignpreview.com issuer=/C=US/O=DigiCert Inc/CN=DigiCert TLS RSA SHA256 2020 CA1 -----BEGIN CERTIFICATE----- MIIGwDCCBaigAwIBAgIQAhJSKDdyQZjlbYO5MJAYOTANBgkqhkiG9w0BAQsFADBP MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMSkwJwYDVQQDEyBE ... JAKQLQ== -----END CERTIFICATE----- Bag Attributes: <No Attributes> subject=/C=US/O=DigiCert Inc/CN=DigiCert TLS RSA SHA256 2020 CA1 issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA -----BEGIN CERTIFICATE----- MIIEvjCCA6agAwIBAgIQBtjZBNVYQ0b2ii+nVCJ+xDANBgkqhkiG9w0BAQsFADBh MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3 ... -----END CERTIFICATE----- Bag Attributes localKeyID: 9D BD 22 80 E7 B2 B7 58 9E AE C8 42 71 F0 39 E1 E7 2B 57 DB Key Attributes: <No Attributes> -----BEGIN ENCRYPTED PRIVATE KEY----- MIIFDjBABgkqhkiG9w0BBQ0wMzAbBgkqhkiG9w0BBQwwDgQI7eNh2qlsLPkCAggA ... FHE= -----END ENCRYPTED PRIVATE KEY-----인증서에는 최소 최종 엔터티 인증서 및 중간 인증서가 포함되어야 합니다. 루트 CA 인증서도 포함하는 것이 좋습니다.
알림:.p12 또는 .pfx 파일이 암호로 보호되어 있는지 확인합니다.
-
자체 서명된 클라이언트 인증서 만들기(선택 사항)
클라이언트 인증서는 필요에 따라 CA 발급이거나 자체 서명일 수 있습니다.
자체 서명된 클라이언트 인증서를 생성하려면 다음 openssl 명령을 사용합니다.
openssl req -newkey rsa:4096 -keyform PEM -keyout ca.key -x509 -days 3650 -outform PEM -out ca.cer
경고:결과 파일은 자체 서명된 CA 인증서이므로 기밀 상태로 유지합니다.
다음으로 클라이언트 .p12 파일을 생성:
- SSL 클라이언트에 대한 개인 키 생성:
openssl genrsa -out client.key 2048
- 클라이언트의 개인 키를 사용하여 인증서 요청 생성:
openssl req -new -key client.key -out client.req
- 인증서 요청 및 CA 인증서/키를 사용하여 클라이언트 인증서 발급:
openssl x509 -req -in client.req -CA ca.cer -CAkey ca.key -set_serial 101 -extensions client -days 365 -outform PEM -out client.cer
- 클라이언트 인증서 및 개인 키를 브라우저에서 사용할 수 있도록 pkcs#12 형식으로 변환:
openssl pkcs12 -export -inkey client.key -in client.cer -out client.p12
- pkcs12에 필요한 모든 것이 있으므로 클라이언트 개인 키, 클라이언트 인증서 및 클라이언트 요청 파일을 제거합니다.
rm client.key client.cer client.req
- SSL 클라이언트에 대한 개인 키 생성:
-
Postman에서 내 PFX 파일을 확인 받은 후에도 Acrobat Sign에서 파일을 거부하는 이유는 무엇입니까?
위의 pfx 파일 확인 프로세스를 따랐는데도 Acrobat Sign에서 pfx 파일을 계속 거부하면 비표준 PKCS12 파일을 생성할 수 있는 Microsoft 도구로 파일이 생성되었기 때문일 수 있습니다.
이 경우 아래 openssl 명령을 사용하여 pfx 파일에서 인증서 및 개인 키를 추출한 다음, 올바른 형식의 PKCS12 파일을 생성합니다.
// pfx 파일에서 인증서 및 개인 키 추출 openssl pkcs12 -info -in microsoftclientssl.pfx -passin pass:"" -out clientcert.crt -nokeys openssl pkcs12 -info -in microsoftclientssl.pfx -passin pass:"" -out clientcert.key -nodes -nocerts // 새 PKCS12 파일 생성 openssl pkcs12 -export -inkey clientcert.key -in clientcert.crt -out clientcert.pfx
