Salesforce Secured Callout

在應用系統介接時，使用 Web API 是目前常見的手段；Salesforce 也提供這樣的模式，無論是扮演 service provider (使用內建的 SOAP Web Services，或是自訂 RESTful API)，或是 service consumer，都有對應的支援；其中當 Salesforce 扮演 service consumer 時，最常見的是使用 Apex 自行呼叫外部 Web API，這種呼叫模式在 Saleforce 中稱為 callout。

在安全性方面，系統介接時一般會優先討論連線方面的安全性，更嚴謹的才會觸及資料面的安全性；這邊我們只討論前者，也就是透過 TLS 對 HTTP 加密，這樣的外部呼叫稱為 secured callout。

值得注意的是：Salesforce 在實作 secured callout 時，對簽發 target service 憑證的 CA 只認可正向表列中 root CA 簽發的憑證 [1] [2]，然而這份列表有些陳舊 [3]，許多常見的 root CA 都不在列表中，例如 TWCA Global Root CA，若 target service 不是自有的服務，無法變更憑證時，可能會被迫使用未加密的 HTTP。

另外在 protocol 版本上，Salesforce 支援 TLS 1.1 與 1.2 [4]，TLS 1.0 由於可降階至 SSL 3.0 且 SSL 3.0 設計上有安全性缺陷，因此目前已停用 TLS 1.0 [5]。

除了 secured callout 外，另一個會使用到憑證的場合是：使用 Salesforce 實作自訂的網站，並掛上自家的網域名稱；這時候對於憑證的限制比前者稍微放寬，允許不是由 root CA 直接簽發的憑證。管理者可以新增所需的 intermediate CA 到 Salesforce [6]，但根源的 root CA 仍必須是列表中認可的。

至於新增 custom site 憑證到 Salesforce 時，由於這邊扮演的是 service provider，因此上傳的資訊中必須包括 private key；使用的檔案格式是 Java KeyStore，這方面的基礎知識可以參考 [7]。

see also:
[1] Outbound Messaging SSL CA Certificates
[2] Know More about All the SSL Certificates That Are Supported by Salesforce
[2] Salesforce Community Idea: Manage List of Trusted Certificate Authorities 
[3] Summer '15 Release Notes: Test and Use Advanced Networking Protocols
[4] Salesforce Disabling TLS 1.0

[5] How do you install an Intermediate CA (SSL) for a force.com page?

[6] SSL Certificate Standards

[7] Salesforce Community Idea: Allow Self-signed Certs for Authenticating Callout Servers

[8] Making Authenticated Web Service Callouts Using Two-Way SSL

SSL Certificate Standards

要搞懂系統認證之前，首先要對非對稱式加密有基礎瞭解，不外乎就 2 種 key：

• Public key: 用於加密與驗證簽章
• Private key: 用於解密與產生簽章

至於這兩把 key 的產生通常會由共同信任的第三方，也就是 CA (Certificate Authority) 發出。[1]

Standards: Encoding Rules & Formats

接下來可能會遇到各種檔案，這裡頭牽涉的標準主要有 2 類：

1. Encoding rule: 說明內容要如何編碼，主要有 DER 與 PEM [2] 兩種，前者的輸出為 binary，後者為 base64。
2. Message or file format: 定義檔案應該包括那些資訊，主要有 PFX, P12 (PKCS #12), CSR (PKCS #10), X.509

• PFX 或 P12 (PKCS #12) [3]: 也就是 CA-signed certificate；這類檔案帶有 private key，一般會被保護起來，很少複製傳遞。
• CSR (PKCS #10) [4]: Certificate Signing Request; 為 client 向 CA 要求簽發憑證時使用，帶自身站台資訊，最少使用。
• X.509 [6] 或 P7C (PKCS #7) [7]: 最常見，用於存放 public certificate 或 signature，其中 P7C 預定為 BER encoding，因此不會與其它 encoding rule 併用。

File Name Extensions

上頭這些標準名稱都常見於副檔名，譬如說：

•  *.pfx 與 *.p12 一定是 CA-signed certificate，未指定 encoding rule，但通常為 binary，可與 PEM 合併使用。
•  *.p7c 一定是 public certificate，固定為 BER encoding。
•  *.der 與 *.pem 通常僅為 public certificate，用副檔名描述編碼方式。

除此，*.cer 與 *.crt 也是常見的副檔名，大多也僅為 public certificate，可套用任何 encoding rule。

最後是這些 key 如何被保存到 client 與 server；對系統來說，存放位置分為 TrustStore 或 KeyStore，分別存放扮演 consumer 與 provider 時，使用的 public certificate 與 private keys。

• 與一般 symmetric authentication 所稱的 certificate 一詞不同，symmetric authentication 中的 certificate 多半為 username/password，但這邊的 certificate 泛指 signature 或包含 private key。
• 例如：CA-signed certificate 即為兩者組合，而 public certificate 則為 signature。所以當單純看到副檔名 *.crt 或 *.cer，並無法確定內容是否包括 private key，類似的情況也發生在 *.pem 的檔案。

ps. Java 的 KeyStore 副檔名通常為 *.jks，由於 KeyStore 用來存放 CA-signed certificate 的關係，有些系統便使用 Java KeyStore 檔取代 *.pfx 或 *.p12，作為匯入 CA-signed certificate 時使用。


see also:
[1] Public Key Infrastructure
[2] PEM (Privacy-enhanced Electronic Mail): Base64 encoded DER certificate
[3] PKCS #12: Personal Information Exchange Syntax Standard
[4] CSR (Certificate Signing Request)
[5] PKCS (Public Key Cryptography Standards)
[6] X.509
[7] PKCS #7: Cryptographic Message Syntax
[8] DER vs. CRT vs. CER vs. PEM Certificates and How To Convert Them