Set up a local PKI CA using OpenSSL or EJBCA.

Hey, welcome back! Remember our last post, "Implement certificate management with a PKI for VPN authentication"? A lot of you chimed in with questions about spinning up your own local PKI CA using OpenSSL or EJBCA. So today, we’re rolling up our sleeves and tackling this together—step by step, from start to finish.

Let’s be real: trusting a third-party certificate authority for your internal security sometimes feels like giving your house keys to a random neighbor. Sure, it works, but wouldn’t you rather know exactly who’s got access? That’s why building your own local PKI CA (Certificate Authority) is such a game-changer. Whether you’re an IT pro, a network admin, or just the person everyone calls when “the VPN is broken,” learning this skill puts you in the driver’s seat for your organization’s security.

Why bother, though? Setting up your own CA isn’t just a tech flex (though, let’s admit, it feels good). It’s practical: you control certificate policies, lifespans, and revocations. You can issue certs for internal services, VPNs, apps, or even your home lab—no more waiting on vendors or exposing sensitive stuff to the outside world.

In this post, we’ll walk through every step of setting up a local PKI CA with two of the most popular tools: **OpenSSL** (the command-line classic) and **EJBCA** (the enterprise powerhouse). I’ll share real commands, config tips, and even a few “oops” moments from my own attempts—believe me, I’ve locked myself out with a bad cert more than once. You’ll also see screenshots and side-by-side comparisons, so you can pick what fits your needs.

Here’s what you’ll get:

- The basics of local CAs and why you might need one  
- Step-by-step guides for OpenSSL and EJBCA, with real commands and config examples  
- Tips for managing and distributing certificates safely  
- Common pitfalls (and how to recover—because we all mess up sometimes)
- A clear comparison of OpenSSL vs. EJBCA, so you can choose what’s right for you

Nobody nails this on the first try, and that’s totally fine. We’re in this together. By the end, you’ll be ready to issue and manage your own certificates—and your network will be safer, more flexible, and future-proof.

Ready to take control? Let’s jump in!

---

## Table of Contents

1. [Introduction to Local PKI and Certificate Authorities](#introduction-to-local-pki-and-certificate-authorities)
2. [Overview of OpenSSL and EJBCA for Local PKI Setup](#overview-of-openssl-and-ejbca-for-local-pki-setup)
3. []()
 []()
 []()
 []()
 []()
 []()

---



Let’s start at the beginning: these days, it feels like everything needs to be locked down. Whether you’re running a business in Seoul, launching a startup in Berlin, or just fiddling with your home server, you’ve probably seen “PKI” or “Certificate Authority” pop up. But what does it all mean, and why should you care—especially if you just want your internal network to be safe?

자, PKI가 뭔지부터 간단히 볼게요.  
PKI, 즉 Public Key Infrastructure, is the backbone of secure communication. Every user or device gets a pair of cryptographic keys (one public, one private). The public key is for sharing; the private key stays secret. This lets you encrypt data, verify identities, and make sure messages aren’t tampered with. 처음엔 이 키랑 인증서가 너무 많아서 헷갈렸는데, 결국 “정말 네가 맞아?”를 확인하는 시스템이더라고요.

So, what’s a Certificate Authority? Think of it as the trusted notary. The CA issues certificates that link public keys to real identities—servers, users, even smart bulbs. Without a CA, you’re basically trusting random keys, which… yeah, not a great plan.

Why set up your own local CA?  
Let’s break it down:

  Set your own rules—expiry dates, who gets certs, how to handle revoked ones.
  No waiting for a global CA to approve your request.
  No need to pay for every internal cert.

실제로, 싱가포르 사내 인트라넷에 TLS를 도입할 때, 로컬 CA로 인증서 발급과 폐기가 정말 쉬워졌어요. 파리 오피스의 Wi-Fi 802.1X 인증이나, 도쿄 공장 IoT 기기 프로비저닝에도 똑같이 적용할 수 있죠. 한 번은 폐기 설정을 깜빡해서 모든 기기에서 수동으로 인증서를 교체해야 했던 적도 있어요—이 실수는 꼭 피하세요!

 작은 프로젝트엔 OpenSSL이 좋아요. 유연하지만, 커맨드라인에 익숙해져야 해요. 규모가 커지면 EJBCA 같은 관리 도구가 훨씬 편해집니다.

잠깐, 여기서 정리하고 넘어갈게요:  
Setting up a local CA isn’t just for big companies. It’s a smart, scalable way to own your internal security, wherever you are. 그리고, 자동 갱신 한 번 해보면, “왜 진작 안 했지?” 싶을 거예요!



 Always keep your CA private key offline or in a hardware security module (HSM). 진짜 이거 한 번 유출되면 끝장이에요.
 Define clear certificate policies and lifetimes. 너무 길게 잡으면 위험, 너무 짧으면 관리가 힘들어요.
 Regularly update and publish your CRL or use OCSP. 폐기된 인증서가 계속 신뢰받는 일, 생각보다 자주 생깁니다.

---



So, you want to build your own local PKI and you’re eyeing OpenSSL and EJBCA? You’re definitely not alone—these two come up in almost every PKI conversation. Let’s break them down side by side, with real-world pros and cons.

---



OpenSSL is like the Swiss Army knife of PKI. It’s lightweight, runs in the terminal, and lets you generate keys, create CSRs, sign certs, and manage revocation—all with a few commands. 처음에 셀프사인 인증서 만들 때, 한 줄이면 끝나서 깜짝 놀랐어요. 그런데, 여기서 함정: OpenSSL은 정말 미니멀해요. 웹 인터페이스도 없고, 자동화하려면 직접 스크립트를 짜야 하죠. 작은 개발팀이나 테스트 환경엔 오히려 이게 더 편할 수도 있어요.

But, as soon as you need to scale or automate, things get hairy. 예전에 여러 개의 하위 CA를 OpenSSL로 관리하다가, 설정 파일이 산더미처럼 쌓여서 멘붕 온 적 있어요. HSM 연동도 수동 설정이 많아서, 벤더 문서만 하루 종일 봤던 기억이 나네요.

---



EJBCA is like the cockpit for enterprise PKI. 웹 콘솔에서 클릭 몇 번이면 인증서 프로필 만들고, 하위 CA 관리하고, 조직 워크플로우에 통합할 수 있어요. 처음에 REST API로 자동 발급하는 거 보고 “이게 진짜 PKI구나!” 싶었죠. 수천 개 인증서를 다뤄야 하거나, 글로벌 조직이라면 EJBCA가 훨씬 편합니다. HSM 연동도 기본 제공이라, 설정이 훨씬 쉽죠.

But, it’s not lightweight. Java 애플리케이션 서버(WildFly), 데이터베이스, 그리고 꽤 넉넉한 리소스가 필요해요. 저도 처음에 랩탑에 올렸다가 팬이 미친 듯이 돌았어요.

---

잠깐, 여기서 정리!

 : 소규모, 수동, 스크립트 중심 환경에 최고. 리소스 적게 먹고, 단순함. 하지만 복잡한 계층 구조엔 힘들어요.
 : 대규모, 자동화, 보안이 중요한 엔터프라이즈에 적합. 리소스와 관리 역량이 필요해요.

여러분도 이런 고민 해보셨죠? 처음엔 OpenSSL로 시작해보고, 규모가 커지면 EJBCA로 넘어가는 것도 좋은 전략이에요.



 OpenSSL 쓸 땐 디렉터리 구조와 파일 관리를 엄격하게 하세요. 파일 하나만 잘못 둬도 인증서 발급이 꼬입니다.
 EJBCA는 설치 전에 충분한 리소스와 안정적인 데이터베이스를 준비하세요. 퍼포먼스가 여기에 달려 있어요.
 HSM 연동이 필요하다면, EJBCA가 훨씬 쉽고 빠릅니다.

---



Thinking about setting up your own local PKI? Exciting, but also a bit intimidating, 맞죠? 제대로 계획하면 나중에 골치 아픈 일 줄일 수 있어요.

  
“누가, 어디서, 어떤 용도로 인증서를 쓸까?” 꼭 리스트로 정리해보세요. 예전에 글로벌 기업 PKI 도입할 때, IoT 기기 수를 너무 적게 잡아서, 나중에 리소스 추가하느라 진땀 뺐던 기억이 있어요. 서버, 사용자, 앱, VPN, 코드 서명 등 다 포함해서 생각하세요. GDPR, HIPAA 같은 규제도 체크!

  
전 세계적으로 표준은 2계층(오프라인 루트 CA + 온라인 중간 CA)입니다. 처음엔 복잡해 보여도, 문제 생겼을 때 복구가 훨씬 쉬워요. 루트 CA는 오프라인(금고에 보관, 정말 필요할 때만 꺼내기)이 기본이에요.

  
이게 진짜 핵심! 가능하면 HSM 쓰세요. 최소한 에어갭 머신에 보관하세요. 저도 한 번 루트 키를 일반 서버에 뒀다가 식은땀 흘린 적 있어요. 다중 인증, 정기 감사 꼭 하세요.

  
가능한 건 다 자동화하세요. EJBCA REST API, OpenSSL 스크립트 등 활용하면, 갱신이나 폐기 때 진짜 편해집니다. 알림 설정, 폐기 연습, 문서화까지 꼼꼼히!

  
PKI 경험 있는 인력이 필요해요. 서버, HSM, 백업 등 하드웨어도 준비하세요. 교육은 필수—저도 매번 새로 배우는 게 있어요.

휴, 복잡하죠? 천천히 하나씩 체크하면, 나중에 훨씬 수월해집니다.



 루트 CA는 항상 오프라인, HSM이나 암호화된 저장소에 보관하세요.
 2계층 구조로 설계하면, 노출 위험이 줄고 관리가 쉬워집니다.
 스크립트나 API로 인증서 라이프사이클을 자동화하세요. 수동 갱신하다가 실수하기 쉽거든요.

---



자, 이제 OpenSSL로 로컬 CA 만드는 법, 진짜 실전으로 들어갑니다. 이거 한 번 제대로 해두면, 개발/테스트 환경에서 “신뢰 안 됨” 경고랑 작별할 수 있어요.



먼저, OpenSSL부터 설치해야죠. 대부분 리눅스에선 한 줄이면 끝!

openssl version

mkdir -p ~/myCA/{certs,crl,newcerts,private}
chmod 700 ~/myCA/private
cd ~/myCA

# 개인키 생성 (암호화)
openssl genpkey -algorithm RSA -aes256 -out private/ca.key.pem -pkeyopt rsa_keygen_bits:4096

# 셀프사인 루트 인증서 생성
openssl req -x509 -new -key private/ca.key.pem -sha256 -days 3650 \
  -out certs/ca.cert.pem \
  -subj "/C=KR/ST=Seoul/L=Seoul/O=MyOrg/OU=MyUnit/CN=MyRootCA"

cp /etc/ssl/openssl.cnf ~/myCA/openssl.cnf

echo 1000 > serial
touch index.txt
echo 1000 > crlnumber

openssl req -new -nodes -out myapp.csr.pem -newkey rsa:2048 -keyout myapp.key.pem \
  -subj "/C=KR/ST=Seoul/L=Seoul/O=ExampleApp/OU=IT/CN=myapp.example.com"

openssl ca -config openssl.cnf -in myapp.csr.pem -out certs/myapp.cert.pem -extensions server_cert

openssl ca -config openssl.cnf -revoke certs/myapp.cert.pem

openssl ca -config openssl.cnf -gencrl -out crl/ca.crl.pem

cp ejbca.war /opt/wildfly/standalone/deployments/

cd /path/to/ejbca
./bin/ejbca.sh install

https://<your-server>:8443/ejbca/adminweb

curl -X POST \
  -u "apiuser:apipassword" \
  -H "Content-Type: application/json" \
  -d '{
    "certificate_profile_name": "ServerProfile",
    "end_entity_profile_name": "Default",
    "username": "webserver1",
    "password": "supersecret",
    "subject_dn": "CN=webserver1.example.com,O=MyOrg,C=US"
  }' \
  https://<your-server>:8443/ejbca/ejbca-rest-api/v1/certificate