Diretório de artigos

1. keytool VS openssl
2. X.509 VS PKCS
3. Software de serviço Web comum e formatos de certificado
referência

//-----------O seguinte é o conhecimento relacionado ao certificado CA e openssl-------------
[certificação SSL, certificado] certificação bidirecional TLS/SSL conceito, exemplo openssl genrsa
[certificação SSL, certificado] comando openssl genrsa explicação detalhada
[certificação SSL, certificado] certificado SSL conceito básico, formato de certificado, diferença entre openssl e keytool

1. keytool VS openssl

keytool e openssl são dois gerenciadores de certificados 工具.

Antes de tudo, uma premissa deve ser confirmada. O certificado gerado pelo keytool está fortemente relacionado à comunicação SSL na linguagem Java. O certificado gerado pelo OpenSSL precisa ser convertido em um formato que o Java possa reconhecer de acordo com o formato correspondente antes que ele possa ser usado.

keytool é uma ferramenta de gerenciamento de certificados que vem com java JDK. Usando keytool pode gerar chaves e criar certificados. Desde que o jdk esteja instalado e as variáveis de ambiente estejam definidas corretamente, você pode executar o comando keytool por meio da linha de comando para gerenciar o certificado.

keytool só pode gerar certificados digitais autoassinados. O chamado certificado autoassinado não é emitido pela agência emissora da CA, mas por ela mesma. Como o certificado raiz da CA não pode ser usado para julgar a validade do certificado, a verificação do certificado só pode ser realizada na forma de um lista branca. Para cada servidor a ser conectado, uma cópia do certificado deve ser copiada com antecedência e colocada no armazenamento de chaves confiáveis (TKS para abreviar). O certificado no TKS é a lista branca de certificados confiáveis, ou seja, comparado com SSL padrão na comunicação Java SSL, JAVA personaliza a verificação de certificados.TKS é projetado para substituir o certificado de detecção CA_ROOT. Portanto, o Keytool tem a desvantagem de precisar ser copiado com antecedência e importado para o TKS como uma lista de permissões.
O openssl é uma biblioteca criptográfica Secure Sockets Layer de código aberto com mais funções que o keytool.

OpenSSL é uma implementação SSL padrão que utiliza cadeias de certificados para autenticação mútua ou unidirecional. A cadeia de certificados significa que a assinatura do certificado tem uma assinatura de assinante pré-implantada e conhecida, de modo que toda vez que você precisar verificar o certificado, você só precisará usar a chave pública do assinante público (o certificado raiz é essencialmente esta chave pública) para verificação. Por exemplo, o navegador que usamos salva vários CA_ROOT comumente usados (ou seja, o certificado raiz que costuma ser chamado). Sempre que você se conectar a um site, desde que julgue que o certificado deste site foi assinado por esses CA_ROOT, ele será reconhecido e verificado.

E o certificado é enviado para a ponta do par através da rede, não há necessidade de copiá-lo para a ponta do par com antecedência, CA_ROOT é predefinido e é uma instituição de CA conhecida, que é muito confiável.

O serviço CA_ROOT compartilhado não é gratuito e caro. Se for uma comunicação interna dentro de uma empresa, você pode usar o CA_ROOT emitido automaticamente para gerar um certificado autoassinado. Ao mesmo tempo, envie o CA_ROOT para o par com antecedência, então o processo de acompanhamento é o mesmo que o padrão O fluxo SSL é o mesmo

2. X.509 VS PKCS

No mundo dos computadores, existem vários padrões de criptografia, que representam como calcular, armazenar, transmitir (etc.) vários algoritmos em computadores, e esses padrões são escritos por organizações padrão como IEFT, ITU-T e ISO.

Antes de discutir essas coisas, aqui está um lembrete de que a chave privada mencionada em alguns lugares abaixo não é na verdade uma chave privada pura (como em RSA
), mas contém todas as informações necessárias de todo o par de chaves A chave (que naturalmente também inclui a chave pública), e é por isso que a chave pública pode ser extraída da chave privada.

Por exemplo, a chave pública RSA está incluída em RSAPrivateKey e a chave pública ECC está incluída em ECPrivateKey.

PKCS 协议组和 X.509 协议均采用 ASN.1 来定义密钥或证书的数据结构. são todas ASN.1 协议implementações concretas.

Visão geral do relacionamento:
insira a descrição da imagem aqui

2.1 PKCS

O nome completo do PKCS é Public-Key Cryptography Standards, ou seja, padrões de chave pública.O PKCS lançou 15 padrões.

PKCS#1 está mais próximo de X.509
…
PKCS#12 contém chaves públicas e privadas na forma de certificados em formato binário, com .pfxum sufixo de arquivo de certificado. Outros tipos de chaves públicas e privadas gerais não serão colocados juntos e geralmente não são .pfxformatados.

Embora seja chamado de padrão de chave pública, ele também contém um padrão de chave privada

padrão	Versão	nome	Introdução
PKCS #1	2.2	Padrão de Criptografia RSA	Fornece propostas para a implementação de criptografia de chave pública baseada no algoritmo RSA, incluindo primitivas criptográficas, esquemas de criptografia, esquemas de assinatura com apêndices e a sintaxe ASN.1 para representar chaves e identificar esquemas. Veja RFC 8017.
PKCS #2	-	depreciar	A transformação originalmente destinada a padronizar resumos criptografados RSA foi incorporada ao PKCS #1.
PKCS #3	1.4	Padrão de protocolo Diffie-Hellman (Padrão de acordo de chave Diffie-Hellman)	Especifica o padrão de acordo de chave baseado no protocolo Diffie-Hellman. Sua função permite que duas partes elaborem uma chave de reunião (chave de sessão) por meio de um acordo.
PKCS #4	-	depreciar	Originalmente usado para padronizar o processo de conversão de chaves RSA. Foi incorporado ao PKCS #1.
PKCS #5	2.1	Padrão de criptografia baseado em senha	Veja RFC 8018.
PKCS #6	1,5	Padrão de sintaxe de certificado estendido	Estenda o padrão de formato de certificado X.509 original.
PKCS #7	1,5	Padrão de sintaxe de mensagem criptográfica	Veja RFC 2315. Especifica o formato da assinatura/texto cifrado gerado pela Public Key Infrastructure (PKI). O mesmo objetivo é ampliar a aplicação dos certificados digitais. Entre eles, S/MIME e CMS (inglês: Cryptographic Message Syntax) estão incluídos.
PKCS #8	1.2	Padrão de sintaxe de informação de chave privada	Sintaxe padrão para armazenar informações de chave privada. Veja RFC 5208.
PKCS #9	2.0	Tipos de atributos selecionados	Define o formato de atributo selecionado para PKCS #6, 7, 8, 10.
PKCS #10	1.7	Padrão de Solicitação de Certificado (Norma de Solicitação de Certificação)	Veja RFC 2986. Padroniza o formato do CSR (solicitação de assinatura de certificado) para solicitar um certificado do centro de certificação.
PKCS #11	2.20	Interface de token criptográfico (Cryptoki)	Define a especificação para a interface de programação de aplicativos (API) de dispositivos criptográficos.
PKCS #12	1,0	Padrão de sintaxe de troca de informações pessoais	Define um formato de arquivo que contém certificados de chave privada e pública . A chave privada é protegida por senha. O formato PFX comum implementa o PKCS #12.
PKCS #13	–	Padrão de criptografia de curva elíptica	em desenvolvimento. Padronizar a aplicação da tecnologia criptográfica desenvolvida com base na criptografia de curva elíptica. A criptografia de curva elíptica é uma nova tecnologia criptográfica e sua força e eficiência são superiores aos algoritmos criptográficos atuais baseados em operações exponenciais. No entanto, a aplicação desse algoritmo ainda não é muito difundida.
PKCS #14	–	Padrão do gerador de números pseudo-aleatórios	em desenvolvimento. Regula o uso e o projeto de geradores de números pseudo-aleatórios.
PKCS #15	1.1	Padrão de formato de informação de token criptográfico	Define a estrutura organizacional dos dados internos do dispositivo criptográfico.

2.2 X.509

X.509 é um padrão de formato para certificados de chave pública em criptografia. Os certificados X.509 foram usados em muitos protocolos de rede, incluindo TLS/SSL, e também em muitos cenários de aplicativos off-line, como serviços de assinatura eletrônica.X.509 证书里含有公钥、身份信息（比如网络主机名，组织的名称或个体名称等）和签名信息（可以是证书签发机构 CA 的签名，也可以是自签名）

Embora seja chamado de padrão de chave pública, ele também contém um padrão de chave privada

2.2.1 Formato de codificação do certificado

DER e perm são protocolos, o primeiro é binário e o último é texto;

2.2.1.1 Formato de codificação de certificado DER binário

X.690 é um padrão ITU-T que especifica vários formatos de codificação ASN.1:

O formato de codificação das regras básicas de codificação (BER, regras básicas de codificação) 抽象, geralmente não usado como um sufixo
Regras de codificação canônica (CER, regras de codificação canônica) binárias, geralmente usadas como o sufixo real
Distinguished Encoding Rules (DER, Distinguished Encoding Rules) binário, um subconjunto de BER, geralmente usado como o sufixo real

BER 是 ASN.1 标准制定的用于将数据编码为二进制格式的原始规则. Coletivamente conhecidas na linguagem ASN.1 como a sintaxe de transferência, essas regras especificam os octetos exatos (bytes de 8 bits) usados para codificar os dados.

DER 是 BER 的子集, que fornece uma maneira de codificar valores ASN.1. O DER é adequado para situações em que são necessárias codificações exclusivas, como em criptografia, e garante que as estruturas de dados que exigem assinaturas digitais resultem em representações serializadas exclusivas. DER pode ser pensado como a forma canônica de BER.

Em termos de criptografia, pode ser simplesmente entendido que os arquivos de chave/certificado de DER 就是 ASN.1 的二进制表达sufixo comumente usados .derarmazenam o binário das regras DER, que podem ser analisadas na estrutura abstrata de ASN.1.

.derPor exemplo, este é o conteúdo de bytes de um arquivo de chave pública X.509 real :

30 82 01 22 30 0D 06 09 2A 86 48 86 F7 0D 01 01
01 05 00 03 82 01 0F 00 30 82 01 0A 02 82 01 01
00 B5 42 F1 89 F0 7D 0D 70 44 D3 CA 3D 6A 94 A8
D8 5A A7 C9 CC 02 8A 23 F7 AB F8 87 A7 3A 60 FC
EC DE 1D 25 8C 27 8D 19 C3 21 84 5C D4 D7 8A 2E
32 BF 66 C1 51 8A 94 B3 72 06 BE D5 B8 41 15 DF
7F C4 1B 55 F4 4A 60 CC 54 0B B8 AD 3F AF AF 71
FC 17 42 78 72 AC 8D 5E BE C3 29 D8 98 6B AA DB
90 86 AB 08 A7 19 FE 33 FB FB 56 23 EE 33 3E F3
95 98 09 38 6C B9 A1 F9 F5 18 94 1B 8E CF D2 F0
27 4B BC 24 52 0C 70 E4 A6 B9 EB 96 60 14 09 BB
7C B7 FF E4 B0 17 A4 28 68 55 D5 1E 5E 84 57 CD
9C E0 FC 35 31 A7 53 80 BE 30 82 94 34 15 C0 75
DB EF A4 BB 01 D7 E6 17 83 52 8B 2E 0E B1 DA C5
32 2D B6 F7 EB 2F AE 3A ED DE 3B FA 3A F8 F2 5D
BC 84 BC E3 F8 BB 1B 5D 85 06 AB C2 B8 8A 82 8E
9D 38 71 79 54 7E 91 FA 7A 14 CF 20 AF 5E 54 22
F1 B6 D3 D2 89 21 43 75 65 3D 74 4B D7 2E 78 52
03 02 03 01 00 01

Seu ASN.1 correspondente é:

SEQUENCE {
    
    
  SEQUENCE {
    
    
    OBJECT IDENTIFIER 1.2.840.113549.1.1.1 rsaEncryption (PKCS #1)
    NULL
  }
  BIT STRING {
    
    
    SEQUENCE {
    
    
      INTEGER 228821442744892501318627381803596567786967739438082404228277133253533…
      INTEGER 65537
    }
  }
}

2.2.1.2 formato de texto pem

Vários padrões relacionados à segurança usados na Internet definem os formatos de dados ASN.1, que geralmente são codificados usando regras básicas de codificação (BER) ou regras distintas de codificação (DER), que são codificações binárias. Uma desvantagem do formato de dados binários é que eles não podem ser trocados em transmissões de texto, como e-mail ou documentos de texto. Uma vantagem das codificações baseadas em texto é que elas são fáceis de modificar usando editores de texto comuns; por exemplo, os usuários podem concatenar vários certificados para formar uma cadeia de certificados com operações de copiar e colar.

O Privacy Enhanced Mail (PEM, Privacy Enhanced Mail) pode ser rastreado até RFC 1421, que é baseado na proposta de Marshall Rose em Message Encapsulation (RFC 934). Originalmente conhecido como "Mecanismo de Encapsulamento PEM", "Mensagem PEM Encapsulada" ou "Codificação PEM Imprimível", hoje o formato é algumas vezes referido como "Codificação PEM". Ele especifica a forma padrão da gramática e declara os caracteres de fim de linha como pares de retorno de carro/alimentação de linha.

Em termos simples, na verdade é 二进制内容用 Base64 编码一下，然后加上-----BEGIN label-----形式的头部和-----END label-----形式的尾部.

No entanto, as RFCs são escritas observando as implementações existentes e documentando o que elas fazem. Os RFCs não foram escritos em primeiro lugar, nem foram baseados em algum documento oficial existente. Portanto, se você deseja interoperar com determinadas implementações, pode ser necessário consultar o código-fonte da implementação para determinar o que elas suportam.

Por exemplo, OpenSSL define isso BEGINe ENDsinaliza em crypto/pem/pem.h. Abaixo está um trecho do arquivo de cabeçalho com todas as tags BEGIN e END que eles suportam.

# define PEM_STRING_X509_OLD     "X509 CERTIFICATE"
# define PEM_STRING_X509         "CERTIFICATE"
# define PEM_STRING_X509_TRUSTED "TRUSTED CERTIFICATE"
# define PEM_STRING_X509_REQ_OLD "NEW CERTIFICATE REQUEST"
# define PEM_STRING_X509_REQ     "CERTIFICATE REQUEST"
# define PEM_STRING_X509_CRL     "X509 CRL"
# define PEM_STRING_EVP_PKEY     "ANY PRIVATE KEY"
# define PEM_STRING_PUBLIC       "PUBLIC KEY"
# define PEM_STRING_RSA          "RSA PRIVATE KEY"
# define PEM_STRING_RSA_PUBLIC   "RSA PUBLIC KEY"
# define PEM_STRING_DSA          "DSA PRIVATE KEY"
# define PEM_STRING_DSA_PUBLIC   "DSA PUBLIC KEY"
# define PEM_STRING_PKCS7        "PKCS7"
# define PEM_STRING_PKCS7_SIGNED "PKCS #7 SIGNED DATA"
# define PEM_STRING_PKCS8        "ENCRYPTED PRIVATE KEY"
# define PEM_STRING_PKCS8INF     "PRIVATE KEY"
# define PEM_STRING_DHPARAMS     "DH PARAMETERS"
# define PEM_STRING_DHXPARAMS    "X9.42 DH PARAMETERS"
# define PEM_STRING_SSL_SESSION  "SSL SESSION PARAMETERS"
# define PEM_STRING_DSAPARAMS    "DSA PARAMETERS"
# define PEM_STRING_ECDSA_PUBLIC "ECDSA PUBLIC KEY"
# define PEM_STRING_ECPARAMETERS "EC PARAMETERS"
# define PEM_STRING_ECPRIVATEKEY "EC PRIVATE KEY"
# define PEM_STRING_PARAMETERS   "PARAMETERS"
# define PEM_STRING_CMS          "CMS"

O formato de arquivo do arquivo PEM:

-----BEGIN (label)-----
/*　　data　　*/
-----END (label)-----

A etiqueta determina o tipo de mensagem codificada, geralmente esses tipos são os seguintes:
"CERTIFICATE", "CERTIFICATE REQUEST", "PRIVATE KEY", "ENCRYPTED PRIVATE KEY" e "X509 CRL".

Por exemplo, X.509 公钥a marcação é:

-----BEGIN PUBLIC KEY-----
-----END PUBLIC KEY-----

X.509 证书está marcado como:

---- BEGIN CERTIFICATE----
/* 证书 */
----END CERTIFICATE----

X.509 证书请求está marcado como:

-----BEGIN CERTIFICATE REQUEST-----
/*    CSR    */
-----END CERTIFICATE REQUEST-----

PKCS #1 公钥está marcado como:

-----BEGIN RSA PUBLIC KEY-----
-----END RSA PUBLIC KEY-----

PKCS #1 加密私钥está marcado como:

-----BEGIN RSA PRIVATE KEY-----
-----END RSA PRIVATE KEY-----

PKCS #8 未加密私钥está marcado como:

-----BEGIN PRIVATE KEY-----
-----END PRIVATE KEY-----

A assinatura da chave privada após a criptografia PKCS #8 é:

-----BEGIN ENCRYPTED PRIVATE KEY-----
-----END ENCRYPTED PRIVATE KEY-----

2.2.2 Extensão do arquivo

Já conhecemos o formato do certificado em binário e forma de texto antes, portanto, para facilitar o usuário a identificar o protocolo e outras informações do certificado, alguns sufixos são acordados. Através do sufixo, o usuário provavelmente conhece algumas informações sobre o certificado

Extensão de arquivo	tipo de arquivo	ilustrar
*.CRT	binário ou formato de texto	A abreviação de Certificado, que significa o arquivo do certificado e contém apenas as informações do certificado, não a chave privada. Usado principalmente em sistemas Linux
*.CER	binário ou formato de texto	Quase o mesmo que o crt acima, significa um arquivo de certificado, usado principalmente no Windows
*.PEM	formato de texto	É um protocolo e um sufixo; o formato de texto é codificado em IDE e geralmente armazena certificados ou chaves privadas, ou certificados e chaves privadas. Se o arquivo .PEM contiver apenas a chave privada, ela geralmente será substituída pelo arquivo .KEY.
*.O	formato binário	É um protocolo e um sufixo; código IDE de formato binário, geralmente armazenando certificados ou chaves privadas, ou contendo certificados e chaves privadas.
.PFX ou .P12	formato binário	Contém o certificado e a chave privada e geralmente é protegido por senha.
.JKS	formato binário	Contém o certificado e a chave privada, geralmente protegida por senha.

Pela tabela acima pode-se observar que:

CER ou CRT é sinônimo de certificado e não contém chave privada.
der e pem são protocolos e podem ser usados diretamente como sufixos para permitir que os usuários saibam se estão armazenados em binário ou texto, mas o conteúdo específico pode ser um certificado ou uma chave
O formato pem pode ser visualizado diretamente através do comando cat, começando com “—–BEGIN…” e terminando com “—–END…”
二进制格式无法直接查看，可以通过 openssl x509 -text -in server.cert 进行查看，此时会转换为以”—–BEGIN…”开头, “—–END…”结尾
二进制和文本之间PEM可以互相转换，因为只是编码格式的转换，你也可以把pem转换为二进制格式
PFX和JKS 是包含证书和私钥的，其他的一定都不含。
- 利用Java的一个叫”keytool”的工具,可以将PFX转为JKS,当然了,keytool也能直接生成JKS
- 此外，证书含有私钥，那么别人获取证书时，要是导出私钥怎么办？很简单，在创建pfx时，有参数可以禁止导出私钥；即使允许导出私钥，你需要提供导出私钥的密码，这个密码保证了不是任何人都能随意导出私钥
BER是编码的基础规范，一般不作为文件的具体后缀名
.csr 是证书请求文件，由客户生成，然后提供给CA签发机构，是由 RFC 2986定义的PKCS10格式，包含部分/全部的请求证书的信息，比如，主题, 机构，国家等，并且包含了请求证书的公玥，这些被CA签发机构中心签名后返回一张证书。返回的证书是公钥证书（只包含公玥不含私钥）。

也就是说公司名称等这些参数是放在请求文件中的，并且含有公钥，一并交给CA机构，公钥怎么来的？是利用私钥生成的，因此这个步骤入参需要私钥。虽然用到了私钥，但是产出的请求文件中，一定不含私钥。

证书签名请求是申请人向证书颁发机构发送的一条消息，用于申请数字身份证书。

有 CSR 必定有 KEY，是成对的，CSR 最终变成为证书 crt，和私钥 key 配对使用。证书下发后，CSR 就没有用了，只是在交时候需要。

3. 常见Web服务软件及证书格式

证书的使用分为2种场景，一种是web服务器，就是我们通过浏览器访问web网站时，由网站侧开启Https，通过443端口进行安全通信，背后实际上是web服务器在起作用，而web服务器能只能识别指定的证书格式；另一个场景就是端到端通信，就是socket编码，此时需要根据不同的语言，来实现具体的证书格式。

O software de serviço da Web comum geralmente é baseado em duas bibliotecas criptográficas básicas, OpenSSL e Java.

O software de serviço da Web, como Tomcat, Weblogic e JBoss, geralmente usa a biblioteca de senhas fornecida pelo Java. Use a ferramenta Keytool no kit de ferramentas Java Development Kit (JDK) para gerar arquivos de certificado nos formatos Java Keystore (JKS) e keystore.

Ambos .keystore e .jks são arquivos usados pelo java para armazenar chaves. Ele permite que os usuários gerenciem seus próprios pares de chaves públicas/privadas e certificados associados para (através de assinaturas digitais) auto-autenticação (usuários se autenticando para outros usuários/serviços) ou integridade de dados e serviços de autenticação. Ele também permite que os usuários armazenem as chaves públicas (na forma de certificados) de seus pares de comunicação.
O software de serviço da Web, como Apache e Nginx, geralmente usa a biblioteca criptográfica fornecida pela ferramenta OpenSSL para gerar arquivos de certificado em formatos como PEM, KEY e CRT.
Os produtos de serviço da Web da IBM, como Websphere, IBM Http Server (IHS), etc., geralmente usam a ferramenta iKeyman que acompanha os produtos IBM para gerar arquivos de certificado no formato KDB.
O serviço Internet Information Services (IIS) no Microsoft Windows Server usa a biblioteca de certificados que acompanha o Windows para gerar um arquivo de certificado no formato PFX.

referência

Conceitos básicos de certificado SSL Alfabetização
Criptografia (2): Padrões de Criptografia - Série X.509 e PKCS
Certificado Digital SSL/TLS Explicação
de Vários Formatos Explicação Detalhada de Vários Formatos de Certificados SSL

[certificação SSL, certificado] Conceito básico de certificado SSL, formato do certificado, diferença entre openssl e keytool