As emocionantes aventuras de um sysadmin linux na procura pelo uptime perfeito!

PKI: Indo de Gnomint para EJBCA

Posted: abril 1st, 2010 | Author: coredump | Filed under: Linux e Open Source, segurança | Tags: , , ,

Uma das coisas que eu sempre me preocupo em fazer ao chegar em um novo trabalho para lidar com infraestrutura é instalar uma série de serviços para ajudar na administração. Isso inclui wikis, monitoramento, um sistema de tickets de serviço, e por ai vai. Outra coisa é criar uma estrutura básica de PKI para emissão de certificados SSL para servidores e outros serviços.

Gerenciar uma Certificate Authority (Autoridade Certificadora ou CA) pode ser feito de várias formas, desde usando os comandos do openssl na mão, passando por utilizar as facilidades de PKI do Active Directory do Windows e algumas ferramentas gráficas como o Gnomint.

Até a semana passada eu estava realmente usando o Gnomint, mas tive uma série de problemas, principalmente com encoding e com um plano de utilizar essa PKI de forma mais ampla. O Gnomint é ótimo para gerenciar pequenas PKIs, mas quando você pensa em emitir milhares de certificados SSL, vocẽ precisa de algo mais parrudo.

Acabei lendo sobre o EJBCA, que é uma aplicação que roda em JBoss e tem uns usuários bem famosos (incluindo o SERASA, aqui no Brasil). O EJBCA foi então a escolha para gerência da PKI.

A instalação dele no Debian (Lenny) foi bem simples, basicamente porque o pacote JBoss do Debian atualmente não faz porra nenhuma, e você tem de baixar o mesmo do site do JBoss e instalar na mão (isso quer dizer descompactar para algum lugar, eu sugiro o /opt). Algumas coisas que eu fiz e podem ajudar:

  • Instalar o JDK6 e o ant via pacote do Debian mesmo: sun-java6-sdk e ant, o ant instala como ant-gcj mas funcionou certinho.
  • Baixar do site da Sun a JCE (Java Cryptography Extensions), e colocar os conteúdos do zip em /usr/lib/jvm/java-6-sun-1.6.0.12/jre/lib/security – isso é necessário para que o Java aceite algumas características mais pesadas em certificados, como senhas com mais de 7 caracteres.
  • Baixe o EJBCA e descompacte no /opt também. Eles não avisam, mas um monte de coisas precisa ser feita desse diretório, ou seja, não se pode simplesmente instalar e apagar, tem de guardar e fazer backup.
  • Configurar as variáveis JAVA_HOME e APPSRV_HOME (apontando para onde está o JBoss) no seu ambiente corretamente. Isso é uma mão na roda e evita que você rode a parada com uma jvm diferente da que você quer. Configure também as variáveis ANT_OPTS e JAVA_OPTS para incluir os parâmetros de memória, eu uso “-Xms128m -Xmx768m” em uma  VM de 1 GB de memória.
  • Se você vai usar poucos certificados, ou está instalando para testar, pode utilizar o banco de dados padrão que é em memória. Caso contrário, instale o postgresql-8.3 (ou mais atual).

Com isso você mata os pré-requisitos do EJBCA. De resto, o guia de instalação dele é bem certinho. Mas basicamente o que você tem de fazer é:

  • Dentro do diretório do EJBCA tem o diretório conf, onde você deve copiar o ejbca.properties.sample para ejbca.properties e configurar. Algumas coisas são bem avançadas como por exemplo guardar as chaves e certificados em dispositivos de hardware, mas no meu caso a maioria dos padrões serviu bem.
  • Leia o arquivo database.properties.sample e o documento howto databases que tem dentro do /doc do EJBCA. Lá tem os comandos para se criar o banco postgres mas basicamente você cria um usuário ejbca com uma senha qualquer, e um banco com este usuário sendo o owner.

O resto do guia é bem mastigado. Lembre-se que o login na interface administrativa só é feito via Certificado, então depois de instalado não perca o arquivo superadmin.p12 queé gerado na instalação e deve ser importado no seu browser para que se possa acessar a interface.

Dentro do diretório do EJBCA existem também documentos descrevendo a utilização de vários servidores de aplicação diferentes assim como outros bancos de dados.

A outra parte foi mais complicada. Eu tinha de pegar os certificados e as chaves privadas das minhas CAs internas do Gnomint e colocá-las no EJBCA. Seria simples, se o Gnomint exportasse o PKCS#12 direito, mas aparentemente ele faz alguma besteira no formato e o EJBCA dá um erro. A solução foi a seguinte, e pode ser utilizada para migração de várias outras formas de PKI para o EJBCA:

  • No Gnomint, exportei separadamente o certificado da minha Root CA para um arquivo e a chave privada da mesma para outro.
  • Usando o openssl, criei um arquivo PKCS#12 usando estes dois arquivos, com o seguinte comando:

sudo openssl pkcs12 -export -out rootca.p12 -inkey rootca.key -in rootca.pem -name privateKey

  • Isso ai cria um arquivo que o EJBCA alegremente importou como a minha nova RootCA, via interface gráfica, sem estresse.
  • Caso você, como eu, tenha de importar CAs subordinadas (sempre uma boa idéia), você tem de repetir o procedimento acima para cada uma (exportar chave e certificado de cada uma), mas tem uma pegadinha: no caso de CAs subordinadas, você tem de incluir no comando openssl a opção -certfile rootca.pem. Porquê disso, você deve perguntar. Porquê sem isso, a cadeia (chain) de certificados fica incorreta no PKCS#12 e quando a Sub CA for importada ela vai aparecer como auto-assinada, e não assinada pela sua Root CA (ou seja, sua cadeia vai ficar quebrada).
  • Eu tive de importar também alguns certificados já emitidos para servidores aqui. Isso não é extremamente necessário, mas se não for feito você vai ficar sem uma forma de revogar estes certificados pelo EJBCA futuramente. Existe uma ferramenta chamada bin/ejbca.sh do EJBCA que faz essa importação sem trauma.

Depois disso, só alegria. O EJBCA tem uma interface pública que fica disponível na porta 8080, onde são publicados as CRL (Certificate Revocation Lists) e também onde usuários podem submeter CSRs (Certificate Signing Request) para geração de novos certificados. A interface administrativa roda na porta 8443 e só pode ser acessada por quem tem o certificado correto instalado no browser, e cuida do resto da PKI.

PKIs são dados sensíveis. Você deve ter backups seguros das configurações e principalmente das keychains das suas CAs. Se você perde uma chave ou um certificado Raiz, você perde toda a segurança que ele propõe, e vai ter de re-emitir TODOS os seus certificados. Lembre-se de limitar o acesso a interface administrativa e a própria máquina, várias camadas de firewall são aconselhadas.

A minha PKI roda numa máquina virtualizada, mas eu não aconselho isso para qualquer lugar onde os certificados serão utilizados em funões críticas. Uma máquina virtualizada é altamente mais sucetível a ataques e a roubo de dados (afinal de contas, se roubar a imagem, rouba-se tudo).

O próximo passo é dar uma conferida na integração do EJBCA com LDAP, para ver como fica uma PKI realmente grande e integrada com outros sistemas.

intel

Compartilhe:
  • Digg
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • LinkedIn
  • Slashdot
  • StumbleUpon
  • Technorati
  • TwitThis
  • Identi.ca
  • Twitter

Posts relacionados:

  1. Usando o Tor e Foxy Proxy para acessar o YouTube E então. Pela segunda vez tenho a impressão de que...
  2. Ele acreditou!!!! E não é que teve gente que acreditou no meu...
  3. Para ser um Sysadmin Vendo o formspring do fike eu tentei me lembrar do...

6 Comments »

6 Comments on “PKI: Indo de Gnomint para EJBCA”

  1. 1 David Marín said at 12:56 on agosto 11th, 2010:

    Hello, I am David Marín, the author of gnoMint.

    What do you think it would be needed so gnoMint can manage a huge CA?

  2. 2 coredump said at 1:28 on setembro 1st, 2010:

    /Hey sorry for the delay.

    Well, what would be needed? In the first place, I left gnomint because encoding errors (my certificate authorities have names with accented characters, and an error somewhere between gnomint and certtool made importing openssl generated csrs impossible to import.

    Things that would make Gnomint interesting for huge CAs: A stronger backend (nobody wants a sqlite crash with thousands of certs on it), a way to automatize CRL exporting to urls (maybe a command line switch to automatically export the CRLs to a given path), user/group or role permission style system allowing the admin to delegate power to users to sign or use only certains CAs or do only certain things on the system.

    The thing is gnomint feels like a desktop program, while it would be better to feel like a multi-user system, IMO. OTOH, my experience with EJBCA was not ver pleasant, and I may end back in gnomint in the next months.

  3. 3 Jorge said at 21:09 on outubro 13th, 2010:

    Olá coredump…
    Li na sua resposta ao David que sua experiência com o EJBCA não está sendo boa… Acha então que o uso do gnomint, apesar dos contras colocados, ainda é a melhor escolha?

  4. 4 Jorge said at 21:15 on outubro 13th, 2010:

    Colocando a pergunta de uma forma melhor, gnomint seria ainda elegível?

  5. 5 coredump said at 21:26 on outubro 13th, 2010:

    Acho que dependendo do tamanho da CA que você vai criar/gerenciar, sim. Só confere se você não vai ter problemas com acentos quando gerar CSRs com openssl e for importar para o Gnomint (caso sua CA tenha acentos, por exemplo).

  6. 6 Rodrigo said at 17:51 on fevereiro 10th, 2011:

    ola coredump. muito bom seu artigo, já dá pra teruma boa idéia da instalação. atualmente eu utilizo como ICP a OpenCA, implementado na empresa com grande esforço, pois tem pouco suporte e adocumentação não é muito abrangente, mas atendia ao escopo das necessidades da empresa, de até 1000 certificados digitais por ano. agora estamos com uma demanda de 20.000 certificados em 2 meses e preciso de uma solucao mais hard e achei a EJBCA com um perfil bem interessante, além de farta documentação e suporte, caso necessário. além, disso, tem gente de peso utilizando a aplicação, como o SERASA Experian. não pretendo migrar meus certificados já emitidos pela OpenCA. quais as reais dificuldades que você teve ao tentar implementar a EJBCA, que te fizeram voltar atrás e utilizar o gnoMint? agradeço seus comentários. rodrigo


Leave a Reply