Como eu emito vários certificados para o mesmo Nome Comum?

3

Estou criando uma autoridade de certificação para uma intranet.

Geramos uma CA raiz e intermediária e assinamos com êxito um certificado do servidor usando a CA intermediária. O certificado do servidor tem CN=mysite.com .

No futuro, esse certificado do servidor expirará e eu precisarei emitir um novo. No entanto, se eu criar outro CSR com o mesmo CN=mysite.com , quando eu assinar, eu obtenho

failed to update database
TXT_DB error number 2

Esse erro desaparece se eu criar um novo CSR com um CN diferente, mas os CNs precisam ser os mesmos ou o navegador não diz que é válido, certo?

Como corrijo isso?

EDIT: Estou seguindo este guia - - tudo está bem até o final da página vinculada, mas quando tento repetir as etapas nesta página para criar um certificado segundo , o openssl exige que eu forneça ao novo certificado um CN diferente.

SUBJ="/C=$C/ST=$ST/L=$L/O=$O/OU=$OU/CN=$CN"

# Generate CSR
echo "$PW" | openssl req \
    -config "$CAROOT/intermediate/openssl.cnf" \
    -new -sha256 -subj "$SUBJ" -passin stdin \
    -key "$PRIV_ENC" -out "$CSR_INT" >/dev/null 2>&1 ||
{
    >&2 echo "Could not openssl req";
    exit 1;
}

# Sign CSR
openssl ca \
    -config "$CAROOT/intermediate/openssl.cnf" \
    -batch -extensions server_cert \
    -days "$HTTP_DAYS" -notext -md sha256 \
    -in "$CSR_INT" -out "$CRT_INT" ||
{
    >&2 echo "Could not openssl ca";
    exit 1;
}

É o openssl ca que falha.

    
por spraff 21.10.2016 / 22:10

2 respostas

5

Você precisa de dupes? Tradicionalmente, os navegadores e clientes exigiam que o campo CommonName do nome do Assunto correspondesse ao nome do host; os modernos preferem que uma entrada na extensão do SubjectAlternativeName (SAN) faça isso. Você pode definir outros campos para diferir, por exemplo,

O=Floo Manufacturing, OU=floo server 2016, CN=www.floo.example.com
O=Floo Manufacturing, OU=floo server 2017, CN=www.floo.example.com

e os Subject DNs são únicos, embora o CommonName por si só não seja. Ou com clientes modernos, você poderia colocar www.floo.example.com em SAN e usar assuntos exclusivos sem CommonName. Mas fazer o openssl fazer por SAN per-cert é um pouco inconveniente; veja por exemplo link

Para permitir dupes: o modo oficial

No seu arquivo de configuração (que é $CAROOT/intermediate/openssl.cnf ), vá para a "seção" (delimitada por linhas do formulário [somename] com espaços em branco opcionais) para sua CA . Como você não usou -name na linha de comando, o nome da seção é o valor de default_ca na seção [ca] ou na seção padrão (na parte superior antes da primeira linha [somename] ); olhando perto do seu link, é provavelmente [CA_default] . Adicione uma linha

 unique_subject=no

com espaçamento e seguindo # comment opcional. Ou se você já tem uma linha para este item, mude e / ou descomente, mas procurando perto do seu link, você provavelmente não o faz.

Consulte a página de manual ca(1ssl) em seu sistema ou a web em OPÇÕES DE ARQUIVO DE CONFIGURAÇÃO.

Para permitir dupes: o caminho não oficial

Esvaziar (truncar) o arquivo database configurado, o qual é convencionalmente index.txt e, olhando próximo ao seu link, eles aparentemente o usam. Ou edite esse arquivo e exclua a (s) linha (s) para o (s) assunto (s) que deseja reutilizar - mas, nessa situação, parece que você tem apenas um ou alguns e você quer reutilizá-lo ou todos eles, então esvaziar o arquivo é mais simples.

    
por 22.10.2016 / 07:40
2

Se você deseja criar vários certificados com o mesmo assunto, altere sua configuração da seguinte forma:

Você pode alterar a seção da CA (provavelmente [CA_default] ) no seu openssl.cnf da configuração

unique_subject = no

Mas esta configuração também é salva no arquivo index.txt.attr , você também precisa alterar isso. Caso contrário, não funcionará.

    
por 30.05.2017 / 19:27