목차

목표

요구 사항

소개

설정

HTTPS 인증서

인증서 프로필

결론

QA

목표

이 가이드는 Omada SDN 컨트롤러에서 SSL/TLS 인증서를 설정하는 방법에 대한 지침을 제공합니다 .

요구 사항

• Omada Controller 6.1
• OpenSSL

소개

Omada Controller는 HTTPS 및 RadSec(TLS 기반 RADIUS)과 같은 서비스의 통신 보안을 위해 SSL/TLS 인증서를 사용합니다. 대부분의 내부 또는 사설 배포 환경에서는 OpenSSL을 사용하여 자체 CA를 유지 관리하는 것이 일반적이며, 이는 일반적인 사용 사례에 간단하고 충분합니다. 대규모 엔터프라이즈 네트워크에서는 인증서 관리를 위해 중앙 집중식 PKI 시스템을 사용할 수 있습니다.

이 문서는 테스트 또는 내부 네트워크 환경에 유용한 자체 생성 인증 기관(CA)을 사용하여 Omada Controller용 인증서를 발급하는 방법에 중점을 둡니다.

설정

HTTPS 인증서

Omada 소프트웨어 컨트롤러는 기본적으로 HTTPS를 사용합니다. 도메인 이름이나 IP 주소로 컨트롤러에 접속할 때 브라우저에 "신뢰할 수 없는 인증서" 또는 "연결이 안전하지 않음"과 같은 경고가 표시될 수 있습니다. 이는 Omada가 자체 서명된 인증서를 사용하기 때문이며, 브라우저는 기본적으로 이를 신뢰하지 않습니다. 신뢰할 수 없는 인증서에 대한 브라우저 경고를 피하려면 신뢰할 수 있는 공인 CA가 서명한 HTTPS 인증서를 가져오거나 개인 또는 내부 CA에서 발급한 인증서를 사용할 수 있습니다.

참고: 자체 CA를 생성하기 전에 컴퓨터에 OpenSSL이 설치되어 있고 명령줄 인터페이스에 접근할 수 있는지 확인하십시오. 개인 키를 안전하게 보호하기 위해 이러한 작업은 로컬 또는 신뢰할 수 있는 환경에서 수행하는 것이 좋습니다. 인증서 파일은 일반적으로 공개적으로 공유해도 안전하지만, 키 파일은 항상 비공개로 유지해야 합니다. 특히 해당 키의 용도나 보안에 미치는 영향을 확실히 알지 못하는 경우에는 더욱 그렇습니다.

1단계. 자체 서명 루트 CA 인증서 생성

openssl genrsa -out rootCA.key 2048

이 명령어는 CA용 2048비트 키 쌍을 생성합니다. 이 키는 인증서 서명에 사용되며 반드시 안전하게 보관해야 합니다.

openssl req -x509 -new -key rootCA.key -days 3650 -out rootCA.pem

이 명령어는 10년간 유효한 루트 인증서(rootCA.pem)를 생성합니다. CA의 개인 키를 사용하여 자체 서명됩니다.

openssl x509 -in rootCA.pem -text

이 명령어를 사용하여 루트 인증서의 상세 내용을 확인할 수 있습니다.

단계 2. 서버 키 및 인증서 서명 요청(CSR) 생성

Omada Controller용 인증서 발급을 준비하려면 먼저 서버 키와 CSR을 생성합니다:

openssl genrsa -out omada.key 2048

이 명령어는 2048비트 RSA 키 쌍을 생성하여 omada.key로 저장합니다. 이 키는 통신 보안을 위해 사용되며 인증서 요청에 서명하는 데 사용됩니다.

openssl req -new -key omada.key -out omada.csr

이 명령어는 이전에 생성된 키를 사용하여 인증서 서명 요청(CSR)을 생성합니다. CSR에는 서버에 대한 정보가 포함되어 있으며 인증 기관(CA)에 인증서를 요청하는 데 사용됩니다.

openssl req -in omada.csr -text

이 명령어를 사용하여 CSR의 상세 내용을 확인할 수 있습니다.

단계 3. 자체 CA를 사용하여 서버 인증서에 서명하기

현대 브라우저는 인증서에 주체 대체 이름(SAN) 필드가 포함되도록 요구합니다. SAN 및 기타 필수 확장을 포함하려면 작업 디렉터리에 server.txt라는 파일을 생성하고 다음 내용을 입력하세요:

# server.txt

[server_cert]

basicConstraints = CA:FALSE

keyUsage = digitalSignature, keyEncipherment

extendedKeyUsage = serverAuth

subjectAltName = @alt_names

[alt_names]

DNS.1 = omada.local

IP.1 = 127.0.0.1

# 끝

참고: DNS.1 및 IP.1 값을 실제 서버의 도메인 이름 또는 IP 주소에 맞게 조정하십시오.

확장 파일 형식에 대한 자세한 내용은 x509v3_config - OpenSSL 문서 및 openssl-x509 - OpenSSL 문서를 참조하십시오.

그런 다음 루트 CA를 사용하여 인증서에 서명합니다:

openssl x509 -req -in omada.csr -CA rootCA.pem -CAkey rootCA.key -days 365 -sha256 -extfile server.txt -extensions server_cert -out omada.pem

생성된 omada.pem 파일이 서버 인증서입니다. omada.key와 함께 사용하면 Omada Controller에서 HTTPS를 활성화할 수 있습니다. 글로벌 > 설정 > 시스템 설정 > HTTPS 인증서에서 업로드할 수 있습니다. 반드시 브라우저의 신뢰할 수 있는 루트 인증서 저장소에 CA 인증서를 가져와야 합니다. 이후 Omada Controller를 재시작하면 변경 사항이 적용됩니다.

인증서 프로필 및 RadSec

RadSec(TLS 기반 RADIUS)는 TLS 암호화를 추가하여 기존 RADIUS를 개선합니다. 표준 RADIUS는 보호 없이 UDP를 통해 실행되는 반면, RadSec은 기밀성, 무결성 및 인증서 기반 인증으로 트래픽을 보호합니다. Omada Controller에서 관리자는 액세스 장치와 RADIUS 서버가 안전한 TLS 터널을 구축할 수 있도록 인증서를 구성합니다. 신뢰할 수 있고 암호화 적용 시의 연결을 보장하려면 RadSec 활성화 전에 적절한 인증서 관리가 필요합니다.

RadSec은 사이트 보기 > 네트워크 구성 > 프로필 > RADIUS 프로필에서 활성화할 수 있습니다.

참고: RadSec을 활성화할 때는 CA 인증서와 클라이언트 인증서를 모두 설정해야 합니다:

CA 인증서: RADIUS 서버의 신원을 등록하는 데 사용됩니다. 액세스 장치는 TLS 터널을 설정하기 전에 서버의 인증서가 이 신뢰할 수 있는 CA에 의해 서명되었는지 확인합니다.

클라이언트 인증서: 액세스 장치가 RADIUS 서버에 자신의 신원을 증명하는 데 사용됩니다. 이를 통해 상호 인증이 보장되어 양측이 서로를 신뢰할 수 있습니다.

인증서 관리를 간소화하기 위해 Omada Controller는 인증서 프로필 모듈을 제공합니다. 이 모듈은 RadSec에 필요한 CA 및 클라이언트 인증서를 저장하고 관리하는 데 사용됩니다.

1단계. 자체 서명 루트 CA 인증서 생성

HTTPS 설정을 위해 자체 서명 CA를 이미 생성한 경우, 동일한 CA를 여기에서 재사용할 수 있습니다. 이 CA는 RADIUS 서버 인증서와 클라이언트 인증서 모두에 서명하는 데 사용됩니다. 아직 생성하지 않은 경우, OpenSSL을 사용하여 자체 서명 CA를 생성하는 방법에 대한 자세한 지침은 HTTPS 인증서 섹션을 참조하십시오.

단계 2. RADIUS 서버 및 클라이언트 인증서 생성

자체 서명된 CA 생성(단계 1) 후 이를 사용하여 두 개의 인증서를 발급합니다: 하나는 RADIUS 서버용, 다른 하나는 액세스 장치용입니다. 상호 신뢰를 구축하려면 둘 다 동일한 CA로 서명되어야 합니다.

2.1 RADIUS 서버 인증서 생성

openssl genrsa -out server.key -aes256 2048

이 명령어는 RSA 키 쌍을 생성합니다. RSA 키는 AES-256으로 암호화 적용 시되며, 이는 RADIUS 서버에서 사용됩니다.

openssl req -new -key server.key -out server.csr

이 명령어는 서버의 신원 정보(일반명, 조직 등)를 포함하는 CSR 파일(server.csr)을 생성합니다. CSR은 CA에 의해 서명되어 유효한 인증서를 생성합니다.

openssl x509 -req -in server.csr -days 3650 -sha256 -CA rootCA.pem -CAkey rootCA.key -out server.pem

이 명령어는 1단계에서 생성한 루트 CA로 CSR을 서명합니다. 결과는 3650일 동안 유효한 서버 인증서(server.pem)입니다.

openssl x509 -in server.pem -text

이 명령어를 사용하면 인증서의 상세 내용을 확인할 수 있습니다.

2.2 클라이언트 인증서 생성

참고: 서버 인증서 생성 과정과 동일합니다. 차이점은 이 클라이언트 인증서가 컨트롤러를 통해 액세스 장치에 할당된다는 점입니다. 이를 통해 액세스 장치는 TLS 핸드셰이크 과정에서 RADIUS 서버에 자신의 신원을 증명할 수 있습니다. CA 인증서와 함께 상호 인증 및 안전한 RadSec 연결을 보장합니다.

openssl genrsa -out 클라이언트.key -aes256 2048

openssl req -new -key 클라이언트.key -out 클라이언트.csr

openssl x509 -req -in client.csr -sha256 -CA rootCA.pem -CAkey rootCA.key -days 365 -out client.pem

3단계 3. 인증서를 CERTIFICATE로 가져오기인증서 프로필

Omada Controller에서 사이트 보기 > 네트워크 구성 > 프로필 > 인증서 프로필을 선택하고 이전 단계에서 생성한 인증서를 추가합니다.

CA 인증서 가져오기

클라이언트 인증서 가져오기

참고: 클라이언트 개인 키 아래의 비밀번호는 클라이언트 키 생성 시 설정한 암호로, 암호화를 통해 키를 보호하는 데 사용됩니다.

4단계. RADIUS 프로필 설정

RADIUS 프로필을 구성할 때 RadSec을 활성화하고 이전 단계에서 생성한 CA 인증서를 참조하십시오. 이 CA 인증서는 TLS 핸드셰이크 중에 RADIUS 서버의 인증서를 등록하는 데 사용됩니다.

클라이언트 인증서는 확인을 위해 서버에 제시됩니다. RADIUS 서버가 클라이언트를 인증하도록 구성된 경우, 서버가 신뢰하는 CA로 서명된 클라이언트 인증서를 지정해야 합니다. 이 CA는 서버 인증서를 발급한 것과 동일하거나(본 문서의 경우) 다른 CA일 수 있습니다. 클라이언트 인증이 필요하지 않은 경우 이 필드는 비워둘 수 있습니다.

결론

OpenSSL을 사용하여 자체 서명 CA를 구축하고, HTTPS, 클라이언트 및 서버 인증서를 성공적으로 발급한 후 인증을 위해 컨트롤러에 업로드했습니다.

각 기능 및 설정에 대한 자세한 내용은 다음을 참조하십시오. 다운로드 센터 에서 해당 제품 설명서를 다운로드하십시오.

다운로드 센터 

QA

Q1: HTTPS 인증서를 설정한 후에도 브라우저에 인증서가 신뢰할 수 없는 것으로 표시되는 이유는 무엇입니까? A1: 첫째, 브라우저에 CA 인증서가 설치되었는지 확인하십시오. 둘째, HTTPS 인증서가 다음 요구 사항을 충족하는지 확인하십시오.

A1: 먼저, 브라우저에 CA 인증서가 설치되어 있는지 확인하십시오. 둘째, HTTPS 인증서가 다음 요구 사항을 충족하는지 확인하십시오:

1. 키 길이는 최소 2048비트여야 하며, 권장 선택은 4096비트입니다.
2. 인증서에는 SAN(Subject Alternative Name) 필드가 포함되어야 합니다.
3. 인증서는 확장 키 사용(EKU) 필드에 의도된 사용 목적을 명시해야 합니다.
4. 인증서 유효 기간은 825일을 초과할 수 없습니다.

마지막으로 다음 명령어를 사용하여 인증서 유효성을 등록할 수 있습니다:

openssl 등록하다 -CAfile <YOUR_CA_CERTIFICATE.pem> <YOUR_SERVER_CERTIFICATE.pem>

Q2: 인증서나 키 파일의 형식을 어떻게 확인할 수 있나요?

A2: 일반적으로 파일 확장자뿐만 아니라 파일 내용을 확인하여 형식을 식별할 수 있습니다.

1. PEM 형식

일반적인 확장자: .pem, .crt, .cer, .key

참고: 파일 내용이 적절한 BEGIN/END 마커로 둘러싸인 Base64 인코딩 데이터로 구성되면 PEM 파일로 인식됩니다. 파일 확장자는 관련이 없습니다.

내용은 사람이 읽을 수 있으며 다음과 같은 줄로 시작합니다:

2. DER 형식

일반적인 확장자: .der, .cer

내용은 이진 형식이며 사람이 읽을 수 없습니다.

확인 방법:

openssl x509 -in <your_cert.der> -inform der -text

3. PFX/PKCS#12 형식

일반적인 확장자: .pfx, .p12

인증서 + 키를 묶은 바이너리 파일

확인 방법:

openssl pkcs12 -in <your_cert.pfx> -info

4. JKS(Java 키 저장소)

일반적인 확장자: .jks

Java에서 사용하는 바이너리 형식

확인 방법:

keytool -list -v -keystore <your_cert.jks>

참고: keytool은 OpenSSL의 일부가 아닙니다. Java 개발 키트(JDK)에 포함되어 있으므로 사용하려면 JDK가 설치되어 있어야 합니다.

이 문서에는 기계 번역이 적용되었으며, 정확한 내용을 확인하려면 원본 영문 문서를 참고하시기 바랍니다.