Conteúdo

Objetivo

Requisitos

Introdução

Configuração

Certificado HTTPS

Perfil de Certificado

Conclusão

QA

Objetivo

Este guia fornece instruções para configurar certificados SSL/TLS no Omada SDN Controller.

Requisitos

• Omada Controller 6.1
• OpenSSL

Introdução

O Omada Controller utiliza certificados SSL/TLS para proteger a comunicação de serviços como HTTPS e RadSec (RADIUS sobre TLS). Na maioria das implantações internas ou privadas, é comum manter sua própria CA usando OpenSSL, pois é simples e suficiente para casos de uso típicos. Redes corporativas maiores podem utilizar sistemas PKI centralizados para gerenciar certificados.

Este artigo foca no uso de uma Autoridade Certificadora (CA) criada pelo próprio usuário para emitir certificados para o Omada Controller, o que é útil para testes ou ambientes de rede internos.

Configuração

Certificado HTTPS

O Omada Software Controller utiliza HTTPS por padrão. Quando você acessa o Controller por nome de domínio ou endereço IP, o navegador pode exibir um aviso como “certificado não confiável” ou “conexão não segura.” Isso acontece porque o Omada utiliza um certificado autoassinado, que não é confiável pelos navegadores por padrão. Para evitar avisos do navegador sobre certificados não confiáveis, você pode importar um certificado HTTPS assinado por uma CA pública confiável, ou usar um emitido por uma CA pessoal ou interna.

Observação: Antes de criar sua própria CA, certifique-se de que seu computador possui o OpenSSL instalado e que você pode acessar uma interface de linha de comando. Recomenda-se realizar estas etapas em um ambiente local ou confiável para manter suas chaves privadas seguras. Arquivos de certificado geralmente são seguros para compartilhamento público, mas arquivos de chave devem sempre ser mantidos privados—especialmente se você não tiver certeza para que a chave serve ou como ela afeta a segurança.

Passo 1. Criar um Certificado Root CA Autoassinado

openssl genrsa -out rootCA.key 2048

Este comando cria um par de chaves de 2048 bits para sua CA. A chave é usada para assinar certificados e deve ser mantida segura.

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

Este comando gera um certificado raiz (rootCA.pem) válido por 10 anos. Ele é autoassinado usando a chave privada da CA.

openssl x509 -in rootCA.pem -text

Você pode usar este comando para visualizar o conteúdo detalhado do certificado raiz.

Passo 2. Gerar a Chave do Servidor e a Solicitação de Assinatura de Certificado (CSR)

Para preparar a emissão de um certificado para o Omada Controller, primeiro gere uma chave de servidor e uma CSR:

openssl genrsa -out omada.key 2048

Este comando gera um par de chaves RSA de 2048 bits e o salva em omada.key. Essa chave será usada para proteger as comunicações e assinar a solicitação de certificado.

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

Este comando cria uma Solicitação de Assinatura de Certificado (CSR) usando a chave gerada anteriormente. A CSR contém informações sobre o servidor e é utilizada para solicitar um certificado a uma Autoridade Certificadora (CA).

openssl req -in omada.csr -text

Você pode usar este comando para visualizar o conteúdo detalhado da CSR.

Passo 3. Assinar o Certificado do Servidor Usando Sua Própria CA

Navegadores modernos exigem que os certificados incluam o campo Subject Alternative Name (SAN). Para incluir o SAN e outras extensões necessárias, crie um arquivo chamado server.txt em seu diretório de trabalho com o seguinte conteúdo:

# 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

# end

Observação: Certifique-se de ajustar os valores de DNS.1 e IP.1 para corresponder ao nome de domínio ou endereço IP real do seu servidor.

Para mais detalhes sobre o formato do arquivo de extensões, consulte a x509v3_config - Documentação do OpenSSL e openssl-x509 - Documentação do OpenSSL.

Em seguida, assine um certificado usando sua CA raiz:

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

O arquivo omada.pem resultante é o certificado do seu servidor, que pode ser utilizado junto com o omada.key para habilitar HTTPS no Omada Controller. Você pode enviá-lo em Global > Settings > System Settings > HTTPS Certificate. Certifique-se de importar o certificado da CA no repositório de certificados raiz confiáveis do seu navegador. Depois disso, reinicie o Omada Controller para que as alterações tenham efeito.

Conclusão

Utilizando o OpenSSL, construímos uma CA autoassinada, emitimos com sucesso certificados HTTPS, de cliente e de servidor, e os enviamos para o Controller para autenticação.

Para conhecer mais detalhes sobre cada função e configuração, acesse o Download Center para baixar o manual do seu produto.

QA

Q1: Por que o navegador ainda mostra o certificado como não confiável mesmo após configurar o certificado HTTPS?

A1: Primeiro, certifique-se de que seu navegador possui o certificado da CA instalado. Segundo, garanta que seu Certificado HTTPS atenda aos seguintes requisitos:

1. O comprimento da chave deve ser de pelo menos 2048 bits, sendo 4096 bits a opção recomendada.
2. O certificado deve incluir o campo Subject Alternative Name (SAN).
3. O certificado deve especificar seu uso pretendido no campo Extended Key Usage (EKU).
4. O período de validade do certificado não deve exceder 825 dias.

Por fim, você pode verificar se o seu certificado é válido usando o seguinte comando:

openssl verify -CAfile <your_ca_certificate.pem> <your_server_certificate.pem>

Q2: Como posso identificar o formato do meu arquivo de certificado ou chave?

A2: Geralmente você pode identificar o formato observando o conteúdo do arquivo (não apenas a extensão)

1. Formato PEM

Extensões comuns: .pem, .crt, .cer, .key

Observação: Um arquivo é reconhecido como PEM se seu conteúdo consistir em dados codificados em Base64 entre os marcadores BEGIN/END apropriados. A extensão do arquivo não é relevante.

O conteúdo é legível por humanos e começa com linhas como:

2. Formato DER

Extensões comuns: .der, .cer

Conteúdo binário, não legível por humanos.

Para inspecionar:

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

3. Formato PFX/PKCS#12

Extensões comuns: .pfx, .p12

Arquivo binário que agrupa certificado + chave

Para inspecionar:

openssl pkcs12 -in <your_cert.pfx> -info

4. JKS (Java Keystore)

Extensão comum: .jks

Formato binário utilizado pelo Java

Para inspecionar:

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

Observação: o keytool não faz parte do OpenSSL. Ele vem com o Java Development Kit (JDK), portanto é necessário ter o JDK instalado para utilizá-lo.

```