> ## Documentation Index
> Fetch the complete documentation index at: https://docs.basaltic.sh/llms.txt
> Use this file to discover all available pages before exploring further.

# Emitir um certificado

> O desafio do DNS começa a terminar, quem publica o CNAME, curingas, e escolhe um algoritmo de chave.

<a id="issuing-a-certificate" />

## Emitir um certificado

A emissão é assíncrona. `POST /v1/certificates` responde **`202`** com o certificado em `pending_dns` e a lista completa de `challenges`. Use os nomes e destinos CNAME retornados imediatamente; você não precisa pesquisar por eles. Se o planejamento de desafios falhar, a criação falhará sem salvar um certificado ou uma lista de desafios parcial.

<Steps>
  <Step title="Criar o certificado">
    <Tabs>
      <Tab title="Console">
        Vá para **Certificates** e escolha **Create Certificate**. Dê um **Name**, adicione cada **Domain** e deixe a fonte em **Auto-issue
        via DNS challenge**.

        O certificado aparece na lista imediatamente e a página de detalhes mostra **Configure DNS to complete certificate issuance** com os registros a serem publicados.
      </Tab>

      <Tab title="API">
        ```bash theme={null}
        POST https://certificate.sa-saopaulo-1.basaltic.sh/v1/certificates
        {
          "name": "prod-frontend",
          "domains": ["example.com", "www.example.com"]
        }
        ```
      </Tab>

      <Tab title="CLI">
        ```bash theme={null}
        basaltic certificate create \
          --name prod-frontend \
          --domains example.com,www.example.com
        ```
      </Tab>

      <Tab title="Go">
        ```go theme={null}
        cfg, err := basaltic.NewConfig(ctx,
            basaltic.WithClientCredentials(os.Getenv("BASALTIC_ACCESS_KEY_ID"), os.Getenv("BASALTIC_SECRET_ACCESS_KEY")),
            basaltic.WithRegion("sa-saopaulo-1"),
        )
        if err != nil {
            log.Fatal(err)
        }

        crt, err := certificate.New(cfg).CreateCertificate(ctx, &certificate.CertificateIssueRequest{
            Name:    "prod-frontend",
            Domains: []string{"example.com", "www.example.com"},
        })
        ```

        Os certificados são regionais, portanto a configuração precisa de uma região.
      </Tab>
    </Tabs>

    `name` é único por conta e aparece no CRN, então ele tem que ser seguro para URLs — letras, dígitos, ponto, traço, sublinhado.

    A resposta de criação inclui um desafio por domínio normalizado, cada um carregando `cname_record_name`, `expected_cname` e `our_dns`. A página de detalhes do console mostra **Auto-criação** quando hospedamos a zona e **Aguardando CNAME** quando você precisa publicar o registro. Use **Copy CNAME name** e **Copy expected value** para copiar suas duas metades.
  </Step>

  <Step title="Publicar o CNAME">
    Cada desafio precisa de `_acme-challenge.<domain>` apontando para o `expected_cname` desse desafio. Se você faz qualquer coisa aqui depende de quem hospeda a zona — veja abaixo.
  </Step>

  <Step title="Aguarde por ativo">
    Solicite `GET /v1/certificates/{certificate_id}` ou atualize a página de detalhes do console para acompanhar o progresso da emissão.

    Cada desafio inverte `verified: true` conforme seu CNAME resolve. Uma vez que cada desafio é verificado e a assinatura é concluída, o certificado torna-se `active` e `certificate_pem`, `fingerprint`, `issued_at` e `expires_at` são preenchidos.
  </Step>
</Steps>

<a id="who-publishes-the-cname" />

### Quem publica o CNAME

<Tabs>
  <Tab title="Domínio em Basaltic DNS">
    O desafio volta com `our_dns: true`. A Basaltic cria o CNAME automaticamente durante a emissão, após a resposta de criação. Você não precisa publicá-lo você mesmo; espere até que `verified` se torne verdadeiro.
  </Tab>

  <Tab title="Domínio hospedado em outro lugar">
    O desafio volta com `our_dns: false`. Adicione o registro no seu registrador, exatamente como o desafio o nomeia:

    ```dns theme={null}
    _acme-challenge.example.com.  CNAME  <expected_cname>
    ```

    Pegue `expected_cname` do desafio em vez de copiá-lo de qualquer outro lugar. O destino é estável para o domínio de validação e é onde o TXT de validação é publicado durante a emissão.

    <Note>
      A delegação é um trabalho único por domínio, não por emissão. Deixe o CNAME no lugar e as renovações serão validadas sem que você precise tocar no DNS novamente.
    </Note>
  </Tab>
</Tabs>

### Wildcards

Um SAN curinga valida em seu nome **pai**, não no SAN literal — isso é [RFC 8555 §8.4](https://datatracker.ietf.org/doc/html/rfc8555#section-8.4). Então um certificado para `*.example.com` precisa:

```dns theme={null}
_acme-challenge.example.com.  CNAME  <expected_cname>
```

O `cname_record_name` do desafio já conta para isso; publique o que ele diz e o caso do curinga cuida de si mesmo.

<Warning>
  Um pedido de curinga só pode ser assinado por uma autoridade com capacidade de curinga. Se nenhum estiver disponível, o certificado falha em vez de voltar para um que não pode emiti-lo.
</Warning>

<a id="key-algorithms" />

## Algoritmos de chave

`key_algorithm` é padrão para **`ecdsa-p256`** e não pode ser alterado após a criação — emita um novo certificado para mudar para um algoritmo diferente.

<Columns cols={2}>
  <Card title="ECDSA" icon="feather">
    `ecdsa-p256` (padrão), `ecdsa-p384`. Teclas menores, apertos de mão mais rápidos. Prefera estes a menos que um cliente exija RSA.
  </Card>

  <Card title="RSA" icon="building">
    `rsa-2048`, `rsa-4096`. Para clientes e dispositivos mais antigos que não negociarão uma cadeia ECDSA.
  </Card>
</Columns>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.