RBIProxy Private CA Requirements
Document Purpose
Used for HTTPS proxying (MITM) signing of RBIProxyPrivate CADefines the technical requirements of __PH_0__.
This document isCustomer PKI ManagerRefer to when issuing and delivering CA.
| item | Content |
|---|---|
| Applicable Products | RBIProxy (Kubernetes Deployment) |
| Follow-up Document | 02. RBIProxy 사설 CA 적용 엔지니어 가이드 |
📌 Summary — Please make sure to check
- Key Algorithm: Current release isRSA 2048bit or higherThis is mandatory. Please use RSA as other algorithms like ECDSA do not guarantee operation.
- Key Format: PKCS#8 PEM PlaintextRequired (
-----BEGIN PRIVATE KEY-----).- Recommended Method: The simplest**"Dedicated Self-Signed Root CA 1"**The method is recommended. The Intermediate CA method is also possible, but please be sure to check the chain transmission constraints in section 4.5.
- Limited Use of this CA: Issue the HTTPS proxy signing certificate for RBIProxy exclusively, and it is necessary to operate it separately from the existing PKI operational CA (code signing, email, etc.).
1. Overview
1.1 Background
RBIProxy intercepts the user's HTTPS traffic.Relay (MITM)It is delivered through the Remote Browser Isolation (RBI) service.
In this process, RBIProxy targets the destination domain (e.g.www.example.com) ofDynamically Reissuing Server Certificatesto provide to the user's browser, to be used as the signer (Issuer) when reissuing.CA certificate/private key pair 1 setThis is needed.
Without using the default CA (included in the product)Utilizing the client's own PKIIf you wish to proceed, you must prepare a CA that meets the requirements of this document.
1.2 When Applying Internal CA is Considered
If any of the following apply, you need to apply your own CA.
- If you want to remove browser warnings related to using the default CA
- Separation of certificates by customer is necessary due to internal security policies.
- When integration and management of the existing internal PKI system is required
- Cases where the use of unique CA is required for audit responses in the financial sector and public sector.
💡 In the PoC or simple testing phase, you can use the default provided CA without any additional work.
1.3 Operation Structure (Summary)
- User PC accessing external sites (e.g.
https://www.example.comRequests HTTPS access via ). - The RBIProxy receives a request,Instant issuance of server certificates for the domain with a private CAand delivers it to the user's browser.
- The user's browser trusts the private Root CA, so the chain validation passes.Without warningIt will be processed normally.
- RBIProxy proxies traffic to actual external sites.
※ For this flow to work, on the user PCPrivate Root CA is a trusted root certificate authoritymust be pre-registered (through AD GPO distribution, etc.).
1.4 Overall Process
| step | subject |
|---|---|
| 1. Review of this document and decision on CA issuance method | PKI Manager |
| 2. CA Certificate/Private Key Issuance | PKI Administrator |
| 3. User PC Root CA Deployment (GPO, etc.) | IT Manager |
| 4. File Transfer Through Secure Channels | PKI Manager → Deployment Manager |
| 5. Reflecting in RBIProxy | Construction Manager |
| 6. Operation Verification | Joint Cooperation |
ℹ️ "Construction Manager"refers to the person responsible for directly working in the Kubernetes environment where RBIProxy is operated. Depending on the setup, this could be an internal IT infrastructure manager, a contracted SI engineer, or an engineer from the product supplier. This term is used consistently throughout this document."
2. Prerequisites
2.1 Required Environment
| division | Requirements |
|---|---|
| Private Root CA | Internal Root CA (or internal PKI) is already in operation. |
| User PC Distribution System | A private Root CA is distributed as a "Trusted Root Certification Authority" on all target PCs (e.g., AD GPO). |
| Deployment Method | Windows System Certificate Store Based (Referencing Edge/Chrome/IE) |
2.2 Scope of Effect
| Browser/Client | support | Note |
|---|---|---|
| Microsoft Edge | ✅ | Using the Windows System Certificate Store |
| Google Chrome | ✅ | Using the Windows System Certificate Store |
| Internet Explorer | ✅ | Using the Windows System Certificate Store |
| Firefox | ⚠️ Separate settings | with GPOsecurity.enterprise_roots.enabled = trueor registered in the local TrustStore |
| Java/.NET and other applications | ⚠️ Separate Response | Separate registration is required in the TrustStore of each runtime. |
| macOS / Linux terminal | ⚠️ Separate Response | Registration of Root CA in each OS certificate store is required. |
3. Files to Deliver (Deliverables)
The following filesSecure Transmission ChannelPlease pass it on to the person in charge of construction.
| # | file | Required/Optional | Format | Description |
|---|---|---|---|---|
| 1 | CA Certificate(Self-Signed Root or Intermediate) | Required | PEM (.crt / .pem) | CA used for signing by RBIProxy |
| 2 | CA Private Key | Required | PKCS#8 PEM Plaintext (.key / .pem) | The corresponding Private Key of the above certificate |
| 3 | Intermediate Chain (Intermediate CAs) | Conditional (Intermediate Method) | PEM Bundle | Include all intermediate CAs between the Root and the issuing CA (excluding the Root) |
| 4 | Root CA Public Certificate | Required | PEM | For verification. If it's a Self-Signed Root method, the same file as #1 is also acceptable. |
3.1 Example of Delivery Format
Option A: Separate File (Recommended)
customer-ca.crt ← #1 (단일 또는 #1+#3 체인 번들)
customer-ca.key ← #2 (PKCS#8 평문)
customer-root-ca.crt ← #4 (검증용)
Option B: Integrated PEM
customer-ca-bundle.pem ← #1 + #2 + #3 모두 포함
customer-root-ca.crt ← #4 (검증용)
Option C: PKCS#12 (.pfx)
customer-ca.pfx ← #1 + #2 + #3 통합 (암호화됨)
* 패스워드는 별도 채널로 전달
customer-root-ca.crt ← #4 (검증용)
ℹ️ RBIProxy runtime isLoad PEM format directlyIf received in PKCS#12 format, the person in charge of the setup will convert it to PEM (cert + key) using OpenSSL. During the conversion process, the private key will be temporarily stored in plaintext, which poses a security risk.**Option A (Separate File)**is needed.
3.2 Secure Transmission Channel (Recommended)
Files containing private keys must be among the following:one or more waysPlease deliver it.
| Method | Recommended Level | Note |
|---|---|---|
| PKCS#12 + Separate Channel for Password Delivery | ⭐⭐⭐ | The file is email, the password is wired/SMS. |
| In-house File Encryption Solution | ⭐⭐⭐ | If you have it |
| Encrypted USB + In-person Delivery | ⭐⭐ | When offline delivery is possible |
| S/MIME Encrypted Email | ⭐⭐ | Mutual certificate exchange required |
| General Email Attachment (Plain Text) | ❌ | Prohibition |
📌 After delivery is complete**Immediately destroy the plaintext file for delivery from the client side.**Please do it.
3.3 Key Format Precautions
The Private Key must meet all of the following conditions.
| item | Required Items |
|---|---|
| Wrapping Format | PKCS#8 PEM (-----BEGIN PRIVATE KEY-----) |
| Key Algorithm | RSA 2048bit or higher(RSA 3072/4096 available) |
| Encryption Status | Plain text(Protected in the transmission channel) |
PKCS#8 Example (Recommended)
-----BEGIN PRIVATE KEY-----
MIIEvQIBADANBgkqhkiG9w0BAQEFAASC...
-----END PRIVATE KEY-----
PKCS#1 (-----BEGIN RSA PRIVATE KEY-----) if you hold — conversion required
openssl pkcs8 -topk8 -nocrypt \
-in customer-ca-pkcs1.key \
-out customer-ca-pkcs8.key
Encrypted PEM(-----BEGIN ENCRYPTED PRIVATE KEY-----) if you hold — Decryption required
openssl pkcs8 -in customer-ca-encrypted.key -out customer-ca-plain.key
# 패스워드 입력 후 평문 PKCS#8로 저장됨
⚠️ The converted/decrypted plaintext private key file isSecure Transmission ChannelPlease refer to section 3.2 and, after transmission is complete, immediately dispose of the original file.
4. Required Requirements for CA Certificates (X.509 Extensions)
CA certificates must meet all of the following requirements. It is not recommended to reuse a CA that has been issued for other purposes (code signing, email protection, etc.), and**"CA for issuing TLS server certificates"**You need to issue a new one. (The same requirements apply to both Self-Signed Root and Intermediate)
4.1 X.509 Extension Field Mandatory Requirements
| Extended Field | Required value | Note |
|---|---|---|
| Basic Constraints | CA:TRUE | Required— Specify that it is a CA certificate |
| Key Usage | keyCertSign, cRLSign | Required— Some browsers trigger warnings when not configured |
| Extended Key Usage (EKU) | serverAuthincluded | Required— Specify the purpose of issuing TLS server certificates |
| Name Constraints | Unconfigured Required | Only the specified domain can be relayed when configured. |
| Path Length Constraint | pathlen >= 0 | end-entity issuance possible |
ℹ️ Key Usage / Extended Key Usageis gradually being validated more strictly in the latest browsers (especially Chrome-based ones). If you set it explicitly, it is safe in terms of compatibility.
4.2 Key/Algorithm Requirements
| item | Required Items |
|---|---|
| Key Type | RSA 2048bit or higher(3072 / 4096 available) |
| Signature Algorithm | Above SHA-256(SHA-1 not allowed) |
| Expiration Date | Needed for more than 3 years |
ℹ️ Other algorithms such as ECDSAis not guaranteed to work in the current release, soRSA usage is mandatoryis.
4.3 OpenSSL Self Check (Before Transmission)
You can check whether the requirements are met with the command below before delivery.
openssl x509 -in customer-ca.crt -noout -text
Check the following items in the output:
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Key Usage: critical
Certificate Sign, CRL Sign
X509v3 Extended Key Usage:
TLS Web Server Authentication
4.4 Chain Validation
openssl verify -CAfile customer-root-ca.crt customer-ca.crt
# 출력: customer-ca.crt: OK
4.5 Chain Transfer Constraints When Operating Intermediate CA
⚠️ This section isConstraints You Must Know When Operating with Intermediate CA MethodIt is. Not applicable if the Self-Signed Root CA method is selected.
Phenomenon
Currently, RBIProxy is for the user's browser.Dynamically issued leaf certificatebut the upper step ofYou may not be able to send the Intermediate CA together..
impact
User PCOnly Root CAIf it is installed, the browser willleaf → (빠진 Intermediate) → RootUnable to complete the chainNET::ERR_CERT_AUTHORITY_INVALIDYou can display warnings such as this.
Solution — Choose either A or B below
A. (Recommended) Use a dedicated Self-Signed Root CA
- Since the chain length is 1 (Root → leaf), there is no intermediate stage → This constraint does not apply.
- Separated from the existing PKI**"1 copy of RBIProxy dedicated Root CA"**issue and deliver
- Only the corresponding Root CA is distributed to the Trusted Root on the user's PC.
B. If you stick to the Intermediate CA method
- User PCMust be distributed to Intermediate CA
- Windows: "Intermediate Certification Authorities" Deploying Intermediate CA to the Repository
- Root CA distribution and GPO deploymentTogether with the same policyinclusion required
- If it is an Intermediate chain of 2 or more levelsAll Intermediate StepsDeployment
Judgment Matrix
| Received CA Types | Certificate to be distributed to user PCs | Browser Behavior |
|---|---|---|
| Dedicated Self-Signed Root CA | Only Root CA | ✅ Normal |
| Intermediate CA (Level 1) | Root CA + Intermediate CA | ✅ Normal |
| Intermediate CA (Level 1) | Only Root CA | ❌ Warning may occur |
| Intermediate CA (Level 2 or higher) | Root CA + All Intermediate CAs | ✅ Normal |
4.6 Key Format Verification
head -1 customer-ca.key
# "-----BEGIN PRIVATE KEY-----" ← PKCS#8 (필수)
# "-----BEGIN RSA PRIVATE KEY-----" ← PKCS#1 (변환 필수)
# "-----BEGIN ENCRYPTED PRIVATE KEY-----" ← 암호화됨 (복호화 필수)
Check Key Algorithm
openssl pkey -in customer-ca.key -noout -text | head -2
# "RSA Private-Key: (2048 bit, 2 primes)" ← 필수
# "ED25519 Private-Key:" 또는 EC 표시 → RSA로 재발급 필요
5. User PC Environment Requirements
5.1 Check Root CA Deployment Status (Windows)
# PowerShell (관리자 권한)
Get-ChildItem Cert:\LocalMachine\Root | Where-Object { $_.Subject -like "*<사내 CA명>*" }
or GUI:certlm.msc → Trusted Root Certification Authorities > CertificatesCheck for the existence of a private Root CA.
5.2 Additional Settings When Using Firefox (Optional)
Firefox uses its own TrustStore by default. To trust the Windows system store, you need to use GPO orpolicies.jsonDeploy the following settings:
{
"policies": {
"Certificates": {
"ImportEnterpriseRoots": true
}
}
}
orabout:config → security.enterprise_roots.enabled = true
5.3 macOS / Linux Terminal Support
| OS | How to Distribute Root CA |
|---|---|
| macOS | Keychain Access→ Add Root CA to system keychain → Trust setting "Always Trust" |
| Ubuntu/Debian | /usr/local/share/ca-certificates/after copying tosudo update-ca-certificates |
| RHEL/CentOS | /etc/pki/ca-trust/source/anchors/after copying tosudo update-ca-trust |
6. Security/Operational Considerations
6.1 Private Key Protection
- The provided CA private key isKubernetes Secretis saved and in the RBIProxy Podread-only volumewill be mounted.
- Secret access rights are managed by the namespace administrator.MinimizationIt works.
- Integration with KMS/HSM can be reviewed separately if necessary.
6.2 Audit Log
Current Operation
- RBIProxy is a dynamically issued leaf certificate'sIndividual issuance history is not logged separately.(performance considerations).
- However, logs of the following categories will be recorded.
- Access Log: External domains accessed by the user (CONNECT log)
- CA Load Event: Pod startup CA private key load success/failure
- Change Secret: Kubernetes Audit Log (Cluster Level)
In cases with strict audit requirements
If there are separate audit requirements such as the need to record the serial number, issuance time, target domain, etc. of the issued leaf certificate, through the person in charge of the constructionSeparate consultationPlease request.
6.3 Certificate Replacement (Rollover)
- CA ExpirationAt least 90 days in advanceNew issuance and delivery are required.
- Replacement can be reflected by recreating the Kubernetes Secret and restarting the Pod (involving a brief session interruption).
6.4 Revocation
- The leaf certificates dynamically issued by RBIProxy containCRL/OCSP URL is not included.(Temporary Issuance Characteristics).
- The CA's own revocation history is recorded in the internal CRL/OCSP system.
6.5 When Changing CA During Operation
- CA replacement isShort session disconnection(Pod restart, typically within 1 minute) is involved.
- to minimize the impact on a large number of usersOff-HoursChanges are needed.
- Before and Afterat least 30 daysPlease do not discard the previous CA during this period and keep it (for rollback purposes).
7. Checklist (For PKI Manager Verification)
Please check the items below before sending.
Common (All Methods)
-
Decision on CA Method: Self-Signed Root CA only or Intermediate CA
-
New issuance of CA for "TLS server certificate issuance"
-
Basic Constraints: CA:TRUE -
Key Usage: keyCertSign, cRLSign(required) -
Extended Key Usage: serverAuthIncluded (Required) -
Name Constraints Not Set (or Include All Domains Subject to RBI Relay)
-
Key Algorithm = RSA 2048bit or higher
-
SHA-256 Signature
-
Validity period of more than 3 years
Private Key Format
-
private keyPKCS#8 PEMFormat (
-----BEGIN PRIVATE KEY-----) -
private keyPlain text(Not encrypted)
User PC Deployment
-
Self-Signed Root CA Method: The corresponding Root CA for all target user PCs**"Trusted Root Certification Authority"**Deployment completed.
-
Intermediate CA method: Root CA is**"Trusted Root Certification Authority"In, Intermediate CA is"Intermediate Certification Authority"**Deployment completed with __PH_0__ (see section 4.5)
Preparation for Delivery
-
openssl verify -CAfile <Root> <Intermediate>Verification OK (Intermediate method) -
Deliver the Root CA public certificate (for verification) together
-
Security Transmission Channel (see section 3.2) ready
-
Pre-determination of the destruction time for plaintext files for transmission
8. FAQ
Q1. Should the private key of the Root CA be shared?
A. No.Do not share the Root CA private key as it is the highest security asset within the company. DedicatedSelf-Signed Root CAto issue a new one or under an existing Root CAIntermediate CAPlease issue and deliver a new one.
Q2. Can I use the existing internal web server certificate as is?
A. It is not possible. General server certificates (end-entity) areCA:FALSEIt was issued and does not have the authority to sign subordinate certificates. A new CA certificate needs to be issued.
Q3. Which one should I choose, Self-Signed CA or Intermediate CA?
A. Dedicated Self-Signed Root CA 1 PageIt is recommended. The Intermediate CA method has the inconvenience of separately distributing the Intermediate to the user PC (see section 4.5). If there are no special requirements such as existing internal PKI integration audits, the Self-Signed method is simple and reliable.
Q4. Can I issue with an ECDSA key?
A. The current release does not guarantee operation, soRSA 2048bit or higherPlease issue it.
Q5. Is it possible to have a CA with a short validity period (such as 1 year)?
A. Technically possible, but there is a burden of re-transmission/re-distribution every year.more than 3 yearsThis is needed.
Q6. Can I provide a CA restricted by Name Constraints?
A. It is possible, but domains not included in the Name Constraint will trigger a browser warning when accessed through RBIProxy. Please ensure to accurately agree on the scope of the domains to be proxied by RBI before setting it up.
Q7. The private key format is PKCS#1 (-----BEGIN RSA PRIVATE KEY-----) Can I send it as it is?
A. Not available.openssl pkcs8 -topk8 -nocryptIt needs to be converted and passed after the command (see section 3.3).
Q8. I only have a PKCS#12 (.pfx) file. Can I send it as is?
A. It is possible to deliver. However, since the RBIProxy runtime uses PEM, the implementation team will convert it to PEM internally and reflect it. From a security perspective, from the beginning**Separated PEM file (Option A)**It needs to be delivered.
Q9. What happens to the service when the certificate expires?
A. Leaving an expired CA as is may cause a browser warning when creating a new session, which could prevent normal use of the RBI service.Prepare for renewal 90 days before expirationPlease do it.
Q10. Can different CAs be used for different environments (production/staging)?
A. Yes, it is possible. You can create Kubernetes Secrets separately for each environment and mount them separately in each environment's Deployment. Separating the CAs for production and staging is necessary because it ensures that even if the staging CA is compromised, it will not affect the production environment.