Clever Geek Handbook

OpenSSL e Network Security Services (NSS) são os dois lados da mesma moeda

imagemDe que medalha está falando o título? Estamos falando de uma infraestrutura de chave pública (PKI / PKI) baseada em padrões de criptografia de chave pública (Public Key Cryptography Standards - PKCS) A infraestrutura de chave pública inclui muitos objetos e mecanismos diferentes para trabalhar com eles, bem como protocolos para a interação de objetos entre si (por exemplo, TLS, OCSP). Os objetos PKI / PKI incluem certificados x509 e pares de chaves (chaves privadas e públicas), documentos assinados e criptografados (pkcs # 7, CMS), contêineres seguros para armazenar chaves privadas (pkcs # 8) e certificados privados com chaves (pkcs # 12), etc. Os mecanismos incluem não apenas funções criptográficas que permitem criptografar e assinar documentos usando vários algoritmos, mas também funções que formam objetos finais de PKI de acordo com padrões (certificados, solicitações, documentos assinados / criptografados, pacotes de protocolo, etc., etc.) .P.). Sim, e como não lembrar o objeto central PKI / PKI -Centro de Certificação (CA).



Qualquer internauta, sem saber, utiliza diversos mecanismos e objetos PKI / PKI, por exemplo, o protocolo HTTPS ao acessar diversos sites, ao assinar e / ou criptografar seus e-mails ou utilizar uma assinatura eletrônica no workflow.

As ferramentas mais avançadas para criar infraestrutura de chave pública, ferramentas de software PKI / PKI são OpenSSL e Network Security Services (NSS).

OpenSSL é um conjunto completo de bibliotecas e utilitários criptográficos de código aberto que oferece suporte a quase todos os algoritmos de hashing, criptografia e assinatura eletrônica de baixo nível e também implementa a maioria dos padrões criptográficos populares, incluindo: permite que você crie RSA, DH, DSA, chaves EC, problema Certificados X.509, criptografar e assinar dados e criar conexões SSL / TLS.

Deve-se notar que os objetos com os quais o utilitário OpenSSL trabalha são armazenados em arquivos (certificados, chaves). Network Security Services (NSS) é o



mesmo conjunto de bibliotecas e utilitários criptográficos de código aberto completos .



A principal diferença entre OpenSSL e NSS é que OpenSSL assume que os certificados e as chaves são armazenados em arquivos, enquanto o NSS usa bancos de dados e tokens PKCS # 11 para armazenar certificados e chaves .

O mais importante é que ambos os projetos (OpenSSL e NSS) sigam estritamente os padrões e, portanto, não há problemas quando são usados ​​juntos em projetos diferentes. Um bom exemplo de sua comunidade pode ser, por exemplo, o uso do protocolo HTTPS, quando sites / portais são construídos com base no Apache com mod_ssl baseado em OpenSSL, e são acessados, por exemplo, através do Firefox, que suporta TLS 1.0 / TLS 1.2 e TLS 1.3 realizado usando as bibliotecas NSS.



Será mostrado abaixo como os utilitários OpenSSL e NSS podem ser usados ​​para resolver os mesmos problemas. No futuro, todos podem usar os utilitários de sua escolha.

Qualquer pessoa pode se familiarizar com as funções da biblioteca examinando o código-fonte deste ou daquele utilitário.



Ver certificados e outras entidades armazenadas em arquivos



Há um utilitário no pacote OpenSSL - openssl , o primeiro parâmetro do qual é o próprio comando (comandos padrão), que deve ser executado:



ajuda $ openssl 
Standard commands
asn1parse         ca                ciphers           cms               
crl               crl2pkcs7         dgst              dhparam           
dsa               dsaparam          ec                ecparam           
enc               engine            errstr            exit              
gendsa            genpkey           genrsa            help              
list              nseq              ocsp              passwd            
pkcs12            pkcs7             pkcs8             pkey              
pkeyparam         pkeyutl           prime             rand              
rehash            req               rsa               rsautl            
s_client          s_server          s_time            sess_id           
smime             speed             spkac             srp               
ts                verify            version           x509              

Message Digest commands (see the `dgst' command for more details)
blake2b512        blake2s256        gost              md2               
md4               md5               rmd160            sha1              
sha224            sha256            sha384            sha512            

Cipher commands (see the `enc' command for more details)
aes-128-cbc       aes-128-ecb       aes-192-cbc       aes-192-ecb       
aes-256-cbc       aes-256-ecb       base64            bf                
bf-cbc            bf-cfb            bf-ecb            bf-ofb            
camellia-128-cbc  camellia-128-ecb  camellia-192-cbc  camellia-192-ecb  
camellia-256-cbc  camellia-256-ecb  cast              cast-cbc          
cast5-cbc         cast5-cfb         cast5-ecb         cast5-ofb         
des               des-cbc           des-cfb           des-ecb           
des-ede           des-ede-cbc       des-ede-cfb       des-ede-ofb       
des-ede3          des-ede3-cbc      des-ede3-cfb      des-ede3-ofb      
des-ofb           des3              desx              idea              
idea-cbc          idea-cfb          idea-ecb          idea-ofb          
rc2               rc2-40-cbc        rc2-64-cbc        rc2-cbc           
rc2-cfb           rc2-ecb           rc2-ofb           rc4               
rc4-40            rc5               rc5-cbc           rc5-cfb           
rc5-ecb           rc5-ofb           seed              seed-cbc          
seed-cfb          seed-ecb          seed-ofb          zlib              
$




Como você pode ver, quando o comando openssl help é executado, além da lista de comandos em si, uma lista de algoritmos de hash e algoritmos de criptografia suportados é exibida (sua lista inclui as funções de compactação e base64).



Para visualizar o certificado (x509), solicitação (req) ou lista de revogação de certificado (crl), basta executar o seguinte comando:



openssl x509 [| req | crl] [-nameopt utf8] -inform PEM | DER -noout -in <nome do arquivo> ...



Por exemplo, o comando: 



$openssl x509 -text -nameopt utf8 -inform PEM -noout -in cert.pem


exibirá na tela do computador o conteúdo do certificado na forma técnica (x509 -texto) armazenado no arquivo cert.pem (-in cert.pem) codificado em PEM (base64) (-inform PEM) e contendo caracteres na codificação utf-8 (-nameopt utf8). Nesse caso, o próprio certificado em codificação PEM não será exibido na tela (-noout).



No pacote NSS, o utilitário pp faz o mesmo .



O utilitário pp é um utilitário Pretty Print para um arquivo que contém uma estrutura ASN.1 na codificação DER ou PEM: 



Usage:  pp [-t type] [-a] [-i input] [-o output] [-w] [-u],
onde digite:

  • c - certificado;
  • cr - solicitação de certificado;
  • pk - chave pública;
  • pk - arquivo de chave pública;
  • crl - lista de certificados revogados.


Observe outro tipo que se aplica aos certificados, ci (identidade do certificado). Este tipo permite obter informações de identificação do certificado, como assunto (proprietário), emissor (editor), número de série (número de série), impressão digital (impressões digitais SHA-1 e SHA-256). O utilitário openssl para x509 possui parâmetros semelhantes.



Por padrão, todos os objetos são considerados codificados por DER. Se os objetos estiverem na codificação PEM, o parâmetro "-a" deve ser especificado (análogo ao parâmetro "-inform PEM" do utilitário openssl). E mais um parâmetro "-u" é definido se o objeto contiver caracteres na codificação UTF-8. Lembre-se de que o utilitário openssl tem um parâmetro semelhante - "-nameopt utf8".



O pacote NSS também contém um utilitário para visualizar a estrutura ASN.1 de um objeto, um análogo do utilitário openssl asn1.parse. Este é o utilitário derdump: 



$derdump -i < > [-o < >]


Pelo próprio nome do utilitário, segue-se que ele funciona com arquivos no formato codificado por DER. Mas está tudo bem. O pacote inclui dois utilitários que convertem arquivos da codificação PEM / BASE64 para a codificação DER e vice-versa. Esses são os utilitários atob e btoa.



Por exemplo, para converter um certificado do formato PEM para o formato DER no OpenSSL, execute o seguinte comando: 



$openssl x509 -inform der -in CERT.der -out CERT.pem


No NSS, seria assim: 



$btoa -in CERT.der -out CERT.pem -w "CERTIFICATE"


A opção "-w" especifica qual texto incluir no início e no final do arquivo de saída. Neste caso, "-w ​​CERTIFICATE" resultará no cabeçalho e trailer do OpenSSL padrão PEM: 



-----BEGIN CERTIFICATE-----
<    BASE64>
-----END CERTIFICATE-----


O OpenSSL e o NSS podem funcionar com contêineres pkcs # 12. E ambos permitem não apenas criar, mas também visualizar o conteúdo do contêiner pkcs12. Mas, ao usar o utilitário openssl, você primeiro precisa analisar o contêiner e salvar os certificados do contêiner em arquivos separados. Depois disso, você pode visualizá-los com segurança. No NSS, a exibição do conteúdo de um contêiner pode ser feita em uma única passagem. Para fazer isso, use o utilitário pk12util da seguinte forma: 



pk12util -l <   pkcs12> [-W <   pkcs12>] [-d <  NSS>] [-h <>]


Por exemplo:



$ pk12util -l cert_RSA.p12 -W 01234567 
Certificate(has private key):
    Data:
        Version: 3 (0x2)
        Serial Number: 3 (0x3)
        Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption
        Issuer: "CN=CA-RSA"
        Validity:
            Not Before: Thu May 21 09:50:00 2020
            Not After : Fri May 21 16:17:00 2021
        Subject: "CN=soft.lissi.ru"
        Subject Public Key Info:
            Public Key Algorithm: PKCS #1 RSA Encryption
            RSA Public Key:
                Modulus:
                    a2:f3:e1:63:fd:4f:60:4e:a9:de:56:37:a6:be:54:f3:
                    3d:67:9a:68:9e:f1:47:69:e3:3a:10:b0:2e:88:0c:ef:
                    7c:7f:48:47:6b:c0:75:63:c7:13:23:88:9a:ff:9a:48:
                    30:6a:a0:52:53:6f:4e:e5:84:c0:a1:b0:50:a2:ab:3d:
                    f9:62:2c:d8:30:be:19:1b:c9:f4:b8:20:57:a1:8e:5e:
                    61:8c:a7:50:91:44:61:99:71:40:bb:dc:4c:b7:7c:67:
                    be:a0:71:26:9f:af:dd:69:63:84:7d:93:3f:92:1b:fb:
                    d1:78:d7:95:75:42:8e:14:a8:63:e2:7b:7d:ef:c8:74:
                    35:7c:39:44:82:ad:92:1f:98:0e:91:95:c8:d8:bd:41:
                    fc:44:7e:4d:f5:94:d1:cc:25:ea:df:69:d7:b1:d7:86:
                    ad:4d:03:f1:35:65:03:a6:84:f8:26:6e:9b:d3:c9:67:
                    d5:a5:a4:9e:c7:82:76:28:9f:90:14:f1:16:6a:29:5d:
                    f8:df:c6:6c:e4:21:0d:6f:c5:87:61:a0:65:e3:97:0f:
                    96:42:ad:7d:96:79:ef:1d:ab:6c:e3:a0:da:3a:65:d8:
                    39:69:f3:20:e2:b1:27:fe:cb:4c:8c:0c:f5:76:f2:65:
                    a0:c7:bb:08:b0:f5:50:c0:96:8a:30:e9:75:f7:56:65
                Exponent: 65537 (0x10001)
        Signed Extensions:
            Name: Certificate Basic Constraints
            Critical: True
            Data: Is not a CA.

            Name: Certificate Key Usage
            Usages: Digital Signature
                    Non-Repudiation
                    Key Encipherment

            Name: Certificate Subject Alt Name
            DNS name: "lissi.ru"

            Name: Certificate Type
            Data: <SSL Server>

            Name: Certificate Comment
            Comment: "xca certificate"

    Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption
    Signature:
        12:8c:c3:7e:e9:18:5a:d7:ee:f8:10:8b:72:55:ba:ee:
        8b:85:6c:aa:e3:de:58:26:a2:da:15:c6:3b:15:d9:82:
        6d:02:33:16:cc:0c:84:9d:96:b0:67:d4:63:10:b5:42:
        a1:c3:de:cb:40:6f:9b:9b:eb:c1:98:b6:66:55:ae:88:
        56:14:02:5c:62:8c:bc:22:97:94:cf:53:da:2e:47:c1:
        c6:83:dc:39:6f:0b:b8:39:4e:66:89:a3:9d:51:c6:e3:
        bd:fc:9e:f3:7b:02:a4:77:bc:08:4e:89:e6:57:54:5c:
        c1:cc:83:93:9e:4e:f5:41:4e:b5:13:bc:64:29:a9:8d:
        ce:13:ae:48:6c:21:fc:da:2a:a2:87:67:f8:df:23:53:
        08:a3:11:93:69:91:84:40:4b:58:c1:f3:d0:78:dc:33:
        f6:a5:a6:6f:ed:39:a9:ec:f3:48:e8:06:09:4c:c3:9f:
        9c:0f:58:80:7f:f5:09:40:2a:f1:cf:42:d7:5b:57:62:
        99:e7:dc:a5:31:f3:9d:1f:5a:88:c2:30:1b:8c:ec:69:
        8b:87:dc:4c:08:9e:70:49:3d:5e:7b:8f:6f:98:50:8b:
        0d:b9:8f:c1:7e:9b:1f:c2:76:3a:ca:c5:e3:3d:ea:93:
        81:c0:3b:e2:b7:d1:5d:e4:fd:48:d6:1b:8f:96:e2:18
    Fingerprint (SHA-256):
        D3:38:99:C9:8B:A5:49:96:BC:26:7B:10:1E:2A:7C:4B:55:15:E5:94:47:C6:D0:49:44:2E:48:58:1B:CF:83:7E
    Fingerprint (SHA1):
        D5:26:80:B7:CE:40:5B:54:85:F6:B2:31:58:C3:3E:9D:A4:3D:C1:F3

    Friendly Name: soft.lissi.ru

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1 (0x1)
        Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption
        Issuer: "CN=CA-RSA"
        Validity:
            Not Before: Wed May 20 16:12:00 2020
            Not After : Tue May 21 16:12:00 2030
        Subject: "CN=CA-RSA"
        Subject Public Key Info:
            Public Key Algorithm: PKCS #1 RSA Encryption
            RSA Public Key:
                Modulus:
                    a3:ca:c1:3b:ac:17:1b:32:69:90:8c:70:3b:95:3e:78:
                    4c:90:55:27:2a:25:05:16:54:d3:88:69:b0:43:a0:20:
                    3d:ca:0d:a2:f9:a5:2f:8c:e1:69:b6:df:79:bd:25:7d:
                    aa:71:2b:f2:9f:82:f1:e7:49:cf:fa:3c:b6:6f:80:09:
                    b2:ee:d5:18:e3:3d:96:67:38:cb:9c:e8:e5:76:c4:a8:
                    0b:b9:ad:dd:42:25:c7:da:cf:d4:15:41:bf:b0:0e:4f:
                    d1:9c:b7:d0:b1:32:a0:c7:14:67:ba:a2:9a:e7:23:26:
                    d7:7e:32:d9:5d:15:47:9e:4b:b0:b1:8b:04:38:1e:c3:
                    b2:fc:17:fe:8e:d1:cb:de:de:fd:13:17:b3:0e:5b:58:
                    e1:37:c7:12:32:b6:94:82:77:b8:4c:87:99:c6:c3:7d:
                    51:ed:3c:41:73:31:aa:13:de:26:84:e7:f7:a9:34:e9:
                    b3:9e:7d:aa:91:65:79:a7:14:9d:fc:45:42:de:e6:43:
                    9d:67:96:94:66:38:0b:2e:32:0a:4d:c3:3d:14:b9:06:
                    6b:e0:92:e2:35:0c:8f:78:7f:2c:ad:ec:dc:67:66:0b:
                    8c:47:82:c5:0e:39:a5:35:75:b5:fb:7f:2d:07:97:ef:
                    15:d8:fc:d4:72:6a:da:32:86:9e:64:ea:4a:e3:37:5b
                Exponent: 65537 (0x10001)
        Signed Extensions:
            Name: Certificate Basic Constraints
            Critical: True
            Data: Is a CA with no maximum path length.

            Name: Certificate Key Usage
            Usages: Certificate Signing
                    CRL Signing

            Name: Certificate Type
            Data: <SSL CA,S/MIME CA,ObjectSigning CA>

            Name: Certificate Comment
            Comment: "xca certificate"

    Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption
    Signature:
        24:90:ac:91:3f:13:f6:1a:d4:3c:1b:de:33:e1:4a:0c:
        d8:27:a0:00:d2:43:c8:1b:13:90:93:d3:d2:f0:fe:79:
        da:14:fd:34:2e:3a:f4:fc:c8:71:c9:4f:0d:65:c0:fd:
        40:04:92:ef:7e:72:35:09:4a:08:1e:ed:21:53:06:03:
        73:f9:13:e7:a3:9c:e2:17:9c:25:b2:a5:f9:dc:07:7d:
        32:9f:cd:82:85:6c:26:79:dd:ee:e7:31:4e:10:55:19:
        d6:ac:1e:70:39:01:d2:37:00:3b:41:de:a9:c2:bd:bf:
        b4:c1:f8:8d:bd:d4:6b:95:6d:53:f3:17:76:40:d4:05:
        a4:1e:69:e8:54:92:91:bf:89:b6:ba:45:c5:14:89:bb:
        f4:44:cf:91:ca:16:44:55:86:8f:b9:37:4e:9e:9e:04:
        cd:48:e7:57:ec:c8:e2:72:f3:df:34:49:0a:9b:3f:67:
        a4:01:dd:f3:a3:bb:ec:b5:b8:20:f5:7e:45:8e:ae:53:
        7e:b8:92:38:0a:b7:41:8e:81:15:ab:72:42:f7:37:4a:
        6d:d7:4f:aa:0a:99:ee:9b:49:16:54:03:42:d6:fe:c1:
        ee:63:71:28:b1:84:c2:e6:d4:7b:f6:10:4c:a0:7a:39:
        9d:03:30:ff:78:24:ce:5b:ac:fe:ac:6d:f6:61:77:a6
    Fingerprint (SHA-256):
        AA:1F:B9:29:D2:F9:CC:AB:3D:F7:8C:26:26:4B:51:A3:71:01:1A:94:F8:FE:47:1D:BD:E3:72:DD:63:17:FE:6C
    Fingerprint (SHA1):
        B3:7A:A1:65:01:E2:A0:09:F4:55:17:EC:40:88:5C:42:9A:45:F5:36

Key(shrouded):
    Friendly Name: soft.lissi.ru

    Encryption algorithm: PKCS #12 V2 PBE With SHA-1 And 3KEY Triple DES-CBC
        Parameters:
            Salt:
                08:0b:8d:be:fa:fc:a5:a3
            Iteration Count: 2048 (0x800)
$




O utilitário é conveniente, mas não sem uma mosca na sopa. A mosca na sopa é que as letras russas, ou melhor, a codificação UTF-8, são exibidas como pontos (.....). E se o utilitário pp tiver o parâmetro -u (codificação utf-8 está presente), então eles se esqueceram dele aqui (vamos enfrentar isso novamente ao considerar o utilitário certutil). Não é difícil corrigir isso: basta adicionar uma linha à função P12U_ListPKCS12File localizada no arquivo pk12util.c: 

PRIntn
P12U_ListPKCS12File(char *in_file, PK11SlotInfo *slot,
                    secuPWData *slotPw, secuPWData *p12FilePw)
{
    SEC_PKCS12DecoderContext *p12dcx = NULL;
    SECItem uniPwitem = { 0 };
    SECStatus rv = SECFailure;
    const SEC_PKCS12DecoderItem *dip;
/*    UTF-8*/
    SECU_EnableUtf8Display(PR_TRUE);

.   .   .   .   .

}


Depois disso, não haverá problemas com letras russas.
$ pk12util -l 1000.p12 -d "." -W 01234567

Certificate(has private key):

Data:

Version: 3 (0x2)

Serial Number: 4096 (0x1000)

Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption

Issuer: «E=ca@test.ru,OGRN=1111111111111,INN=222222222222,CN=

,OU=

,O= ,STR

EET=». , . 0",L=,ST=

,C=RU"

Validity:

Not Before: Tue Jul 07 08:40:14 2020

Not After: Fri Aug 06 08:40:14 2021

Subject: «E=test@rsa.ru,CN= »

Subject Public Key Info:

Public Key Algorithm: PKCS #1 RSA Encryption

RSA Public Key:

Modulus:

9a:9f:6c:60:94:f7:ec:f7:94:b3:51:01:e2:1a:c5:25:

28:bb:02:77:49:52:4d:99:8a:6e:26:12:55:8f:71:34:

04:da:39:24:f9:b4:6b:d0:0a:42:27:1b:b2:d7:9b:d9:

c3:76:b0:e0:1c:7c:21:ce:79:9f:d5:2b:17:63:cb:94:

5b:d9:b2:53:ff:b9:bf:4f:3d:cf:b7:8d:8a:37:ba:02:

8c:da:d2:0d:fd:46:5b:45:1d:95:64:07:6e:fa:88:0d:

a4:bd:b3:4a:ed:99:f1:fd:73:c5:b6:05:a0:e5:ee:6b:

c3:83:5b:d0:64:05:77:6a:18:d8:c8:28:a1:d0:06:41:

23:0d:bb:87:8a:77:14:fb:6c:5d:af:db:2b:0b:11:a3:

16:1b:2b:05:18:26:a9:b5:00:4a:40:da:b3:05:aa:2a:

67:c0:18:0d:03:f7:d2:b9:ba:7c:36:f9:95:2e:56:81:

a3:09:99:5e:20:10:95:38:10:c9:c1:6f:c3:6c:a6:1b:

78:51:c6:e4:4f:11:bc:c0:22:4b:ca:59:16:f2:45:95:

0d:fd:7b:46:cf:c7:ac:1c:3d:d7:26:fc:ad:80:3e:2c:

21:93:29:32:a6:79:e2:a8:c6:e9:5e:45:34:d3:38:57:

8f:cd:95:5e:91:09:84:34:21:d2:16:29:69:75:4d:a3

Exponent: 65537 (0x10001)

Signed Extensions:

Name: Certificate Basic Constraints

Critical: True

Data: Is not a CA.



Name: Certificate Key Usage

Usages: Digital Signature

Key Encipherment

Key Agreement



Name: Certificate Type

Data: <SSL Client,S/MIME>



Name: Extended Key Usage

TLS Web Client Authentication Certificate

E-Mail Protection Certificate



Name: Certificate Subject Key ID

Data:

26:a1:b3:98:1c:fe:62:ba:23:81:96:37:3f:08:bd:70:

d6:f2:b1:46



Name: Certificate Authority Key Identifier

Key ID:

0a:b6:f6:87:64:1d:8e:b3:63:08:29:9f:21:59:ad:47:

d8:ea:07:f4

Issuer:

Directory Name: «E=ca@test.ru,OGRN=1111111111111,INN=22222222

2222,CN= ,OU=

,O=

,STREET=».

, . 0",L=,ST=

,C=RU"

Serial Number:

00:a2:9b:22:32:3e:a7:3d:d8



Name: Certificate Subject Alt Name

RFC822 Name: «test@rsa.ru»



Name: Certificate Issuer Alt Name

Error: Parsing extension: Certificate extension value is invalid.

Data: Sequence {

}



Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption

Signature:

2f:75:7e:71:9e:15:5c:97:fe:a2:e1:2a:52:39:56:55:

e0:62:60:bc:5f:6d:c2:b6:ec:cd:8b:10:b3:b1:3f:e5:

d6:d1:5f:a5:fa:61:c1:ce:3e:db:6a:2f:b2:13:46:8d:

67:cf:18:09:61:97:01:45:bc:99:bb:0c:d6:0a:a3:03:

87:0a:8e:10:3a:d5:e3:94:6d:4a:24:fa:c3:40:0b:43:

c2:3b:00:56:06:c4:d2:fc:b2:7e:e9:00:e5:2f:4b:e2:

3a:91:49:ce:f8:c3:60:ec:01:74:d8:1a:3b:af:e6:f6:

91:db:c5:f1:d7:de:be:18:38:47:41:8a:e2:ef:80:91:

10:54:41:ae:55:22:6f:d7:8c:fa:46:b6:b6:2a:ee:6a:

0c:c9:03:18:af:4e:93:6c:61:f3:b4:78:0c:61:93:f1:

d8:1b:00:c3:e5:29:9a:08:0a:f8:31:67:88:3d:c3:88:

7a:60:c0:c4:52:94:25:56:e5:a3:df:7d:58:c5:df:9a:

c7:22:7e:2c:f6:fb:2c:bf:b7:7f:c5:ca:2b:0f:8c:20:

77:b9:1f:e0:62:5a:3d:d4:6f:12:ea:c8:51:67:a5:75:

ad:e9:ac:9e:4e:2e:2d:34:80:e7:d8:64:f6:8f:2f:33:

32:1f:8b:bc:9c:e8:77:4a:ee:7b:84:31:ec:28:e9:70

Fingerprint (SHA-256):

96:F4:A5:FA:6D:8A:F8:7E:A6:10:49:BD:43:34:C1:92:C6:7D:FF:63:41:8E:69:C0:AC:34:6B:CB:63:7B:56:31

Fingerprint (SHA1):

B6:91:9B:C6:7A:45:9C:92:FD:E7:C7:33:00:FA:91:DF:7D:5F:00:21



Friendly Name:



Certificate:

Data:

Version: 3 (0x2)

Serial Number:

00:a2:9b:22:32:3e:a7:3d:d8

Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption

Issuer: «E=ca@test.ru,OGRN=1111111111111,INN=222222222222,CN=

,OU=

,O= ,STR

EET=». , . 0",L=,ST=

,C=RU"

Validity:

Not Before: Tue Jul 07 08:08:11 2020

Not After: Fri Jul 05 08:08:11 2030

Subject: «E=ca@test.ru,OGRN=1111111111111,INN=222222222222,CN=

,OU=

,O= ,STR

EET=». , . 0",L=,ST=

,C=RU"

Subject Public Key Info:

Public Key Algorithm: PKCS #1 RSA Encryption

RSA Public Key:

Modulus:

e7:08:ed:83:08:10:7b:48:56:37:8b:e2:4a:31:1a:7b:

0d:4e:d2:a2:67:d7:04:60:a0:09:db:06:64:21:01:4e:

0d:41:d8:61:15:c6:58:83:66:7e:6b:65:72:0d:2b:c3:

50:26:11:04:82:4b:1a:12:d0:dc:e1:13:1c:76:69:0f:

c2:59:e2:5d:60:6d:fe:8a:48:fa:8b:1e:05:07:34:6d:

8a:e3:76:23:42:9e:7b:64:0b:6a:fb:36:63:31:96:df:

ed:d3:e8:7c:6e:39:d4:7d:da:b8:f4:ec:53:57:60:f1:

d8:a4:3a:3f:3b:4a:63:6c:2a:55:90:21:15:23:4a:37:

21:31:a0:c4:bb:84:0d:96:18:3c:3b:ba:92:e3:e2:17:

56:e5:d9:8c:58:24:8a:a3:53:b6:4f:02:4d:30:a6:0f:

34:ad:20:cf:6f:03:ca:23:1e:d3:15:bc:80:09:d8:1e:

90:07:da:90:a9:34:9e:6e:ed:6b:10:b7:a1:a4:a9:b4:

04:ac:6a:40:d8:00:52:d6:6a:28:f2:8c:c6:84:81:8a:

cd:63:a6:53:82:d2:4e:11:ec:94:81:d7:9c:79:8a:30:

9c:40:75:4d:d9:88:0b:cc:a4:0c:5d:6d:23:a6:ac:56:

8c:49:d9:1f:2b:63:cb:50:fc:a3:e0:3e:35:4e:f4:03

Exponent: 65537 (0x10001)

Signed Extensions:

Name: Certificate Basic Constraints

Critical: True

Data: Is a CA with no maximum path length.



Name: Certificate Subject Key ID

Data:

0a:b6:f6:87:64:1d:8e:b3:63:08:29:9f:21:59:ad:47:

d8:ea:07:f4



Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption

Signature:

17:7d:29:dc:4d:6e:4c:99:7a:bc:b2:2a:a5:80:f9:5f:

0c:60:00:2b:f3:f4:ef:19:d7:ed:56:07:5d:24:e1:b3:

f6:43:e2:05:9b:75:ce:cd:cf:27:1e:1c:cd:d8:cc:43:

77:16:04:7e:8a:dd:89:c4:b2:75:ae:f4:84:23:53:18:

fe:be:c5:1d:40:55:aa:91:9f:f5:96:06:5d:07:22:a8:

1c:b9:29:c4:49:2e:75:10:75:22:95:36:16:58:2f:77:

f5:fa:6d:de:c4:67:ca:f3:e1:98:51:b4:ba:b7:2a:7f:

06:db:33:5a:a6:bb:53:57:f4:18:93:16:9c:0e:43:d0:

46:e6:84:55:bb:ff:68:fe:fa:32:d5:23:2a:d5:65:9b:

d9:63:45:6b:53:71:64:dd:da:e1:40:fa:89:30:b1:73:

8b:f8:7c:3c:2f:72:24:ad:e8:5c:07:89:2f:3a:0d:37:

48:29:1f:0d:5f:9e:11:73:56:b8:d9:24:eb:2d:2e:18:

c7:9b:90:62:09:20:61:75:b9:a1:9a:3f:99:34:8e:06:

30:ce:7d:60:42:7d:e0:14:f2:88:f2:41:a0:46:4d:55:

17:d4:c2:15:64:c9:3e:f5:cc:0a:41:f7:c0:d0:94:96:

ea:64:e0:45:3a:e0:a3:d6:22:a9:d1:e3:c4:51:e8:96

Fingerprint (SHA-256):

F5:DF:15:79:5E:1E:41:84:96:8C:8C:CA:37:0C:A6:BB:C3:21:AE:3D:32:42:8C:63:C2:64:BA:0A:74:DC:37:F8

Fingerprint (SHA1):

CF:C6:B9:D4:3C:16:6F:31:91:2A:09:2F:FE:4C:57:89:0F:5A:F1:DB



Friendly Name:



Key(shrouded):

Friendly Name:



Encryption algorithm: PKCS #12 V2 PBE With SHA-1 And 3KEY Triple DES-CBC

Parameters:

Salt:

c4:fa:4a:6a:4f:54:a1:7a

Iteration Count: 2048 (0x800)

$



Ao criar um contêiner PKCS # 12 com o utilitário openssl, usamos o shell gráfico CAFL63 :







Agora é a hora de falar sobre o repositório NSS.



Armazenamento NSS



O repositório NSS é o diretório no qual três bancos de dados são armazenados.



O banco de dados (DB) cert8.db / cert9.db armazena certificados. O banco de dados key3.db / key4.db armazena chaves privadas. E, finalmente, o banco de dados secmod.db / pkcs11.txt armazena informações (principalmente o caminho para a biblioteca) que permite trabalhar com tokens / cartões inteligentes / nuvens de terceiros com a interface PKCS # 11 .



O utilitário modutil foi projetado para criar um repositório NSS no seguinte formato: 



modutil -create -force [-dbdir < NSS>] , 
< NSS> := [<  >:]<  NSS>
<  > := dbm|sql , :
$modutil -create -force -dbdir "sql:/~/TEST_NSS"


O tipo de banco de dados dbm supõe a criação de bancos de dados Berkeley (cert8.db, key3.db e secmod.db). O tipo sql pressupõe a criação de bancos de dados SQLite3 (cert9.db, key9.db e um arquivo de texto pkcs11.txt). Os bancos de dados SQLite3 são criados por padrão. O diretório do repositório NSS deve ser criado com antecedência. Por padrão (a menos que o parâmetro -dbdir ou -d seja especificado), o armazenamento ".netscape" na pasta pessoal do usuário é usado. Este armazenamento é usado, por exemplo, pelo navegador google-chrome.



Também é fácil criar um armazenamento em um novo formato (SQLite3) (cert9.db, key4.db e pkcs11.txt) a partir do armazenamento de certificados de formato antigo (DBM) (cert8.db, key3.db e secmod.db). Para isso, basta executar o utilitário para trabalhar com certificados certutil no modo de visualização de chaves (-K) ou certificados (-L) com o parâmetro -X, por exemplo: 



$certutil -K -X -d ~/TEST_NSS


ou 



$certutil -L -X -d ~/TEST_NSS


Observe que tais repositórios estão disponíveis em todos os projetos construídos em NSS, incluindo Firefox, Thunderbird, Seamonkey, GoogleChrome, LibreOffice .



Depois de criar o armazenamento NSS, o "Módulo NSS Internal PKCS # 11" integrado com dois tokens integrados torna-se automaticamente disponível: 



$modutil -list -dbdir ~/TEST_NSS
Listing of PKCS #11 Modules
-----------------------------------------------------------
  1. NSS Internal PKCS #11 Module
           uri: pkcs11:library-manufacturer=Mozilla%20Foundation;library-description=NSS%20Internal%20Crypto%20Services;library-version=3.52
         slots: 2 slots attached
        status: loaded

         slot: NSS Internal Cryptographic Services
        token: NSS Generic Crypto Services
          uri: pkcs11:token=NSS%20Generic%20Crypto%20Services;manufacturer=Mozilla%20Foundation;serial=0000000000000000;model=NSS%203

         slot: NSS User Private Key and Certificate Services
        token: NSS Certificate DB
          uri: pkcs11:token=NSS%20Certificate%20DB;manufacturer=Mozilla%20Foundation;serial=0000000000000000;model=NSS%203
-----------------------------------------------------------
$


O token "NSS Generic Crypto Services" implementa funções e mecanismos criptográficos, e o token "NSS Certificate DB" é projetado para armazenar certificados e chaves e outras informações adicionais (por exemplo, sobre como confiar em certificados raiz). O token "NSS Certificate DB" (token NSS interno) usa o banco de dados cert8.db / cert9.db para armazenar certificados e armazena chaves privadas no banco de dados key3.db / key4.db.



Você pode obter informações sobre os tokens integrados do Módulo PKCS # 11 Interno NSS, incluindo os mecanismos criptográficos suportados por padrão, executando o seguinte comando:



$ modutil -list 'Módulo NSS Interno PKCS # 11' -dbdir ~ / TEST_NSS
— Name: NSS Internal PKCS #11 Module

Library file: **Internal ONLY module**

Manufacturer: Mozilla Foundation

Description: NSS Internal Crypto Services

PKCS #11 Version 3.0

Library Version: 3.52

Cipher Enable Flags: None

Default Mechanism Flags: RSA:ECC:DH:RC2:RC4:DES:AES:CAMELLIA:SEED:SHA1:SHA256:SHA512:MD5:MD2:SSL:TLS



Slot: NSS Internal Cryptographic Services

Slot Mechanism Flags: RSA:ECC:DH:RC2:RC4:DES:AES:CAMELLIA:SEED:SHA1:SHA256:SHA512:MD5:MD2:SSL:TLS

Manufacturer: Mozilla Foundation

Type: Software

Version Number: 3.52

Firmware Version: 1.0

Status: Enabled

Token Name: NSS Generic Crypto Services

Token Manufacturer: Mozilla Foundation

Token Model: NSS 3

Token Serial Number: 0000000000000000

Token Version: 4.0

Token Firmware Version: 0.0

Access: Write Protected

Login Type: Public (no login required)

User Pin: NOT Initialized



Slot: NSS User Private Key and Certificate Services

Slot Mechanism Flags: None

Manufacturer: Mozilla Foundation

Type: Software

Version Number: 3.52

Firmware Version: 1.0

Status: Enabled

Token Name: NSS Certificate DB

Token Manufacturer: Mozilla Foundation

Token Model: NSS 3

Token Serial Number: 0000000000000000

Token Version: 0.0

Token Firmware Version: 0.0

Access: NOT Write Protected

Login Type: Public (no login required)

User Pin: Initialized

— $



A conexão de um módulo adicional para trabalhar com dispositivos PKCS # 11 externos é feita com o mesmo utilitário modutil: 



$modutil -add < > -libfile <  > [-dbdir < NSS>]


Por exemplo, para trabalhar com tokens RUToken compatíveis com criptografia russa, basta executar o seguinte comando: 



$modutil -add "ruTokenECP" -libfile /usr/lib64/librtpkcs11ecp_2.0.so -dbdir $HOME/.netscape


Para obter uma lista de módulos que suportam um repositório NSS específico, com informações sobre cada módulo (biblioteca, lista de slots suportados e tokens conectados a eles), execute o seguinte comando: 



$modutil -list [-dbdir < NSS>]


Para obter informações completas sobre os tokens conectados para um módulo específico, você precisará executar o seguinte comando: 



$modutil -list < > [-dbdir < NSS>]


Já o usamos quando recebemos informações sobre os tokens NSS integrados (internos).

E, se você pode adicionar um módulo, também pode remover o módulo do banco de dados: 



$modutil -delete < > [-dbdir < NSS>]


O acesso a tokens externos geralmente é protegido por PIN . Mas o acesso ao token de banco de dados de certificado NSS integrado não é protegido por senha por padrão (código PIN). Mas não é difícil estabelecê-lo, por exemplo: 



$modutil -dbdir $HOME/.netscape -changepw "NSS Certificate DB"


Da mesma forma, você pode alterar o código PIN do token externo.



Agora é a hora de trabalhar com tokens, seus mecanismos e objetos.



Acessando Objetos Token PKCS # 11



O utilitário certutil é usado para acessar objetos (chaves, certificados) de tokens PKCS # 11. Observe que o utilitário certutil é tão funcional quanto o utilitário openssl. Para visualizar a funcionalidade do utilitário certutil, basta executar o comando: 



$certutil -H


Mas agora estamos interessados ​​apenas no acesso a certificados e chaves . Lembre-se de que, quando armazenados em um token PKCS # 11, ambos geralmente recebem os atributos CKA_ID e CKA_LABEL. Para visualizar a lista de certificados em um token específico, execute o seguinte comando: 



$certutil -L [-d < NSS>] [-h < >]


O rótulo do token real ou uma das palavras-chave - tudo ou interno - pode ser especificado como um rótulo do token. No primeiro caso (token label all), todos os tokens conectados ao armazenamento NSS são pesquisados ​​e, no segundo caso (interno ou "BD de certificado NSS"), o token interno do armazenamento "BD de certificado NSS" será visualizado.



Por exemplo, para obter uma lista de certificados em um token denominado "LS11SW2016", o módulo de acesso para o qual está registrado no repositório NSS "/ home / a513 / tmp / TEST_NSS", execute o seguinte comando: 



$ certutil -L -d /home/a513/tmp/TEST_NSS -h "LS11SW2016"
Enter Password or Pin for "LS11SW2016":
Certificate Nickname                                  Trust Attributes
                                                      SSL,S/MIME,JAR/XPI
LS11SW2016:TestCA_P11                                 u,u,u
LS11SW2016:clientnss from CryptoArmPKCS               u,u,u
LS11SW2016:                                   u,u,u
LS11SW2016:Thenderbird-60.3.0 from 32                 u,u,u
LS11SW2016:  from  12_512             u,u,u
LS11SW2016:Text4Key                                   u,u,u
LS11SW2016:KmailKleopatra  GnuPG-2001               u,u,u
LS11SW2016:setvernss from CryptoArmPKCS               u,u,u
LS11SW2016:   from  12_512                       u,u,u
LS11SW2016:Test 12 512                                u,u,u
LS11SW2016:Kleopatra  GnuPG-2001                    ,,   
$


A lista de certificados no token é exibida em duas colunas. A primeira coluna fornece o apelido do certificado e a segunda contém os atributos de confiança desse certificado.



Além disso, se o certificado tiver uma chave privada no token em que está localizado, essa coluna conterá o valor "u, u, u" .



Caso os atributos não tenham sido configurados, a coluna conterá o valor ",,".



Os certificados com atributos de confiança “u, u, u” (eles têm uma chave privada) podem ser usados ​​para autenticação ou para gerar uma assinatura eletrônica.



Outros valores de atributos de confiança podem ser definidos para certificados localizados no token “BD de certificado NSS” incorporado. Mas mais sobre isso mais tarde.



Qual é o apelido de um certificado no NSS? 



<nickname> := [< >:]<CKA_LABEL>


Para um token interno ("Banco de dados de certificado NSS"), o rótulo do token no apelido pode estar ausente.



Se considerarmos os mecanismos dos tokens PKCS # 11, veremos que as operações de geração de chaves, importação de certificados e chaves por si só não permitem definir os valores dos atributos CKA_ID e CKA_LABEL. Tudo isso é repassado ao desenvolvedor do software aplicativo. Mas, se você usar utilitários NSS para trabalhar com tokens, eles resolvem o problema.



O seguinte comando é usado para visualizar a lista de chaves privadas: 



$certutil -K [-d < NSS>] [-h < >]


Isso imprime o tipo de chave, CKA_ID e CKA_LABEL da chave.



Mas voltando aos certificados. Para visualizar o certificado no token, em formato de texto, basta executar o comando: 



$certutil -L [-d < NSS>] -n <nickname >


Por exemplo:



certutil -L -d '/ home / a513 / tmp / TEST_NSS' -n 'Banco de dados de certificado NSS: certificado de teste'
$ certutil -L -d "/home/a513/tmp/TEST_NSS" -n «NSS Certificate DB: »

Certificate:

Data:

Version: 3 (0x2)

Serial Number: 4096 (0x1000)

Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption

Issuer: «E=ca@test.ru,OGRN=1111111111111,INN=222222222222,CN=

,OU=

,O= ,STR

EET=». , . 0",L=,ST=

,C=RU"

Validity:

Not Before: Tue Jul 07 08:40:14 2020

Not After: Fri Aug 06 08:40:14 2021

Subject: «E=test@rsa.ru,CN= »

Subject Public Key Info:

Public Key Algorithm: PKCS #1 RSA Encryption

RSA Public Key:

Modulus:

9a:9f:6c:60:94:f7:ec:f7:94:b3:51:01:e2:1a:c5:25:

28:bb:02:77:49:52:4d:99:8a:6e:26:12:55:8f:71:34:

04:da:39:24:f9:b4:6b:d0:0a:42:27:1b:b2:d7:9b:d9:

c3:76:b0:e0:1c:7c:21:ce:79:9f:d5:2b:17:63:cb:94:

5b:d9:b2:53:ff:b9:bf:4f:3d:cf:b7:8d:8a:37:ba:02:

8c:da:d2:0d:fd:46:5b:45:1d:95:64:07:6e:fa:88:0d:

a4:bd:b3:4a:ed:99:f1:fd:73:c5:b6:05:a0:e5:ee:6b:

c3:83:5b:d0:64:05:77:6a:18:d8:c8:28:a1:d0:06:41:

23:0d:bb:87:8a:77:14:fb:6c:5d:af:db:2b:0b:11:a3:

16:1b:2b:05:18:26:a9:b5:00:4a:40:da:b3:05:aa:2a:

67:c0:18:0d:03:f7:d2:b9:ba:7c:36:f9:95:2e:56:81:

a3:09:99:5e:20:10:95:38:10:c9:c1:6f:c3:6c:a6:1b:

78:51:c6:e4:4f:11:bc:c0:22:4b:ca:59:16:f2:45:95:

0d:fd:7b:46:cf:c7:ac:1c:3d:d7:26:fc:ad:80:3e:2c:

21:93:29:32:a6:79:e2:a8:c6:e9:5e:45:34:d3:38:57:

8f:cd:95:5e:91:09:84:34:21:d2:16:29:69:75:4d:a3

Exponent: 65537 (0x10001)

Signed Extensions:

Name: Certificate Basic Constraints

Critical: True

Data: Is not a CA.



Name: Certificate Key Usage

Usages: Digital Signature

Key Encipherment

Key Agreement



Name: Certificate Type

Data: <SSL Client,S/MIME>



Name: Extended Key Usage

TLS Web Client Authentication Certificate

E-Mail Protection Certificate



Name: Certificate Subject Key ID

Data:

26:a1:b3:98:1c:fe:62:ba:23:81:96:37:3f:08:bd:70:

d6:f2:b1:46



Name: Certificate Authority Key Identifier

Key ID:

0a:b6:f6:87:64:1d:8e:b3:63:08:29:9f:21:59:ad:47:

d8:ea:07:f4

Issuer:

Directory Name: «E=ca@test.ru,OGRN=1111111111111,INN=22222222

2222,CN= ,OU=

,O=

,STREET=».

, . 0",L=,ST=

,C=RU"

Serial Number:

00:a2:9b:22:32:3e:a7:3d:d8



Name: Certificate Subject Alt Name

RFC822 Name: «test@rsa.ru»



Name: Certificate Issuer Alt Name

Error: Parsing extension: Certificate extension value is invalid.

Data: Sequence {

}



Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption

Signature:

2f:75:7e:71:9e:15:5c:97:fe:a2:e1:2a:52:39:56:55:

e0:62:60:bc:5f:6d:c2:b6:ec:cd:8b:10:b3:b1:3f:e5:

d6:d1:5f:a5:fa:61:c1:ce:3e:db:6a:2f:b2:13:46:8d:

67:cf:18:09:61:97:01:45:bc:99:bb:0c:d6:0a:a3:03:

87:0a:8e:10:3a:d5:e3:94:6d:4a:24:fa:c3:40:0b:43:

c2:3b:00:56:06:c4:d2:fc:b2:7e:e9:00:e5:2f:4b:e2:

3a:91:49:ce:f8:c3:60:ec:01:74:d8:1a:3b:af:e6:f6:

91:db:c5:f1:d7:de:be:18:38:47:41:8a:e2:ef:80:91:

10:54:41:ae:55:22:6f:d7:8c:fa:46:b6:b6:2a:ee:6a:

0c:c9:03:18:af:4e:93:6c:61:f3:b4:78:0c:61:93:f1:

d8:1b:00:c3:e5:29:9a:08:0a:f8:31:67:88:3d:c3:88:

7a:60:c0:c4:52:94:25:56:e5:a3:df:7d:58:c5:df:9a:

c7:22:7e:2c:f6:fb:2c:bf:b7:7f:c5:ca:2b:0f:8c:20:

77:b9:1f:e0:62:5a:3d:d4:6f:12:ea:c8:51:67:a5:75:

ad:e9:ac:9e:4e:2e:2d:34:80:e7:d8:64:f6:8f:2f:33:

32:1f:8b:bc:9c:e8:77:4a:ee:7b:84:31:ec:28:e9:70

Fingerprint (SHA-256):

96:F4:A5:FA:6D:8A:F8:7E:A6:10:49:BD:43:34:C1:92:C6:7D:FF:63:41:8E:69:C0:AC:34:6B:CB:63:7B:56:31

Fingerprint (SHA1):

B6:91:9B:C6:7A:45:9C:92:FD:E7:C7:33:00:FA:91:DF:7D:5F:00:21



Mozilla-CA-Policy: false (attribute missing)

Certificate Trust Flags:

SSL Flags:

User

Email Flags:

User

Object Signing Flags:

User

$



Se o certificado visualizado no mesmo token tiver uma chave privada, os Sinalizadores de confiança do certificado terão o valor Usuário:



Certificado de confiança bandeiras:

Bandeiras SSL:

Usuário

E-mail Bandeiras:

Usuário

Assinatura Bandeiras objeto:

Usuários


Para exportar um certificado de um token para a saída padrão, basta adicionar um parâmetro "-a" ou "-r" adicional. A opção "-a" instrui a saída do certificado no formato PEM:



$ certutil -L -d '/ home / a513 / tmp / TEST_NSS' -n 'Banco de dados de certificado NSS: Certificado de teste' -a
-----BEGIN CERTIFICATE-----

MIIGiTCCBXGgAwIBAgICEAAwDQYJKoZIhvcNAQELBQAwggF2MQswCQYDVQQGEwJS

VTEsMCoGA1UECAwj0JzQvtGB0LrQvtCy0YHQutCw0Y8g0L7QsdC70LDRgdGC0Ywx

GzAZBgNVBAcMEtCl0LDQsdGA0LDQs9GA0LDQtDEqMCgGA1UECQwh0YPQuy4g0KXQ

sNCy0YDQvtCy0YHQutCw0Y8sINC0LiAwMTAwLgYDVQQKDCfQo9C00L7RgdGC0L7Q

stC10YDRj9GO0YjQuNC5INCm0LXQvdGC0YAxOzA5BgNVBAsMMtCe0YLQtNC10Lsg

0KPQtNC+0YHRgtC+0LLQtdGA0Y/RjtGI0LjQuSDQptC10L3RgtGAMTAwLgYDVQQD

DCfQo9C00L7RgdGC0L7QstC10YDRj9GO0YjQuNC5INCm0LXQvdGC0YAxGjAYBggq

hQMDgQMBARIMMjIyMjIyMjIyMjIyMRgwFgYFKoUDZAESDTExMTExMTExMTExMTEx

GTAXBgkqhkiG9w0BCQEWCmNhQHRlc3QucnUwHhcNMjAwNzA3MDg0MDE0WhcNMjEw

ODA2MDg0MDE0WjBMMS4wLAYDVQQDDCXQotC10YHRgtC+0LLRi9C5INGB0LXRgNGC

0LjRhNC40LrQsNGCMRowGAYJKoZIhvcNAQkBFgt0ZXN0QHJzYS5ydTCCASIwDQYJ

KoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqfbGCU9+z3lLNRAeIaxSUouwJ3SVJN

mYpuJhJVj3E0BNo5JPm0a9AKQicbsteb2cN2sOAcfCHOeZ/VKxdjy5Rb2bJT/7m/

Tz3Pt42KN7oCjNrSDf1GW0UdlWQHbvqIDaS9s0rtmfH9c8W2BaDl7mvDg1vQZAV3

ahjYyCih0AZBIw27h4p3FPtsXa/bKwsRoxYbKwUYJqm1AEpA2rMFqipnwBgNA/fS

ubp8NvmVLlaBowmZXiAQlTgQycFvw2ymG3hRxuRPEbzAIkvKWRbyRZUN/XtGz8es

HD3XJvytgD4sIZMpMqZ54qjG6V5FNNM4V4/NlV6RCYQ0IdIWKWl1TaMCAwEAAaOC

AkcwggJDMAwGA1UdEwEB/wQCMAAwCwYDVR0PBAQDAgOoMBEGCWCGSAGG+EIBAQQE

AwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFCah

s5gc/mK6I4GWNz8IvXDW8rFGMIIBsAYDVR0jBIIBpzCCAaOAFAq29odkHY6zYwgp

nyFZrUfY6gf0oYIBfqSCAXowggF2MQswCQYDVQQGEwJSVTEsMCoGA1UECAwj0JzQ

vtGB0LrQvtCy0YHQutCw0Y8g0L7QsdC70LDRgdGC0YwxGzAZBgNVBAcMEtCl0LDQ

sdGA0LDQs9GA0LDQtDEqMCgGA1UECQwh0YPQuy4g0KXQsNCy0YDQvtCy0YHQutCw

0Y8sINC0LiAwMTAwLgYDVQQKDCfQo9C00L7RgdGC0L7QstC10YDRj9GO0YjQuNC5

INCm0LXQvdGC0YAxOzA5BgNVBAsMMtCe0YLQtNC10Lsg0KPQtNC+0YHRgtC+0LLQ

tdGA0Y/RjtGI0LjQuSDQptC10L3RgtGAMTAwLgYDVQQDDCfQo9C00L7RgdGC0L7Q

stC10YDRj9GO0YjQuNC5INCm0LXQvdGC0YAxGjAYBggqhQMDgQMBARIMMjIyMjIy

MjIyMjIyMRgwFgYFKoUDZAESDTExMTExMTExMTExMTExGTAXBgkqhkiG9w0BCQEW

CmNhQHRlc3QucnWCCQCimyIyPqc92DAWBgNVHREEDzANgQt0ZXN0QHJzYS5ydTAJ

BgNVHRIEAjAAMA0GCSqGSIb3DQEBCwUAA4IBAQAvdX5xnhVcl/6i4SpSOVZV4GJg

vF9twrbszYsQs7E/5dbRX6X6YcHOPttqL7ITRo1nzxgJYZcBRbyZuwzWCqMDhwqO

EDrV45RtSiT6w0ALQ8I7AFYGxNL8sn7pAOUvS+I6kUnO+MNg7AF02Bo7r+b2kdvF

8dfevhg4R0GK4u+AkRBUQa5VIm/XjPpGtrYq7moMyQMYr06TbGHztHgMYZPx2BsA

w+UpmggK+DFniD3DiHpgwMRSlCVW5aPffVjF35rHIn4s9vssv7d/xcorD4wgd7kf

4GJaPdRvEurIUWelda3prJ5OLi00gOfYZPaPLzMyH4u8nOh3Su57hDHsKOlw

-----END CERTIFICATE-----



Para saída DER, use o parâmetro "-r".



Instale um certificado para um token



Suponha que você tenha um contêiner PKCS # 12 com um certificado pessoal e chave privada que você gerou usando OpenSSL. Para exportar um certificado pessoal para o armazenamento NSS, use o seguinte comando pk12util: 



$pk12util -i < pkcs12> [-d < NSS>] [-h < >]


Se você deseja importar um certificado para um token específico, você precisa definir seu rótulo. Vamos observar mais uma peculiaridade. Se o contêiner contiver certificados raiz, eles serão salvos no token interno "BD de certificado NSS". Isso não define os atributos de confiança padrão. Se, por algum motivo, for necessário definir atributos de confiança para certos certificados de autoridades de registro (certificados raiz) ou certificados SSL, o utilitário certutil da seguinte forma será usado: 



$certutil -M -n <nickname-> -t < > [-d < NSS>]


Para cada certificado, existem três categorias de confiança disponíveis, expressas na seguinte ordem: SSL, S / MIME, assinatura de código para cada configuração de confiança: 



< > := x,y,z ,


  • x - atributos para SSL,
  • y - atributos para S / MIME,
  • z - atributos para assinatura de código.


Cada posição x, y e z pode estar vazia (usar ,, sem confiança explícita) ou conter um ou mais atributos:



  • p - peer válido;
  • P - nó confiável (implica p)
  • c - certificado válido da autoridade de registro (CA válida)
  • T - CA confiável para a emissão de certificados de cliente (c também está implícito)
  • C - CA confiável para a emissão de certificados de servidor (apenas SSL) (c implícito)


Observe que nem todos os tokens externos permitem a operação de importação de uma chave privada para um token.



Para instalar um certificado simples de um arquivo, use o utilitário certutil da seguinte forma: 



$certutil -A -n < > -t < > [-d < NSS>] [-h < >] [-a] [-i <  >]


Infelizmente, neste contexto, <etiqueta do certificado> não é equivalente ao apelido do certificado discutido acima. Aqui, o rótulo do certificado corresponde apenas a CKA_LABEL, apenas rótulos sem especificar um rótulo de token. Algum tipo de inconsistência.



Por padrão, o certificado é considerado em um arquivo codificado por DER. Se o certificado for codificado por PEM, o parâmetro "-a" deve ser especificado. Se o parâmetro "-i" não for especificado, o certificado será obtido da entrada padrão (stdin). Por padrão, os certificados são instalados no token "NSS Certificate DB", mas você pode instalar o certificado em um token externo (parâmetro "-h"). Ao instalar um certificado em um token externo, o certificado será instalado no token interno ("Banco de dados do certificado NSS") e no token externo. Nesse caso, os atributos de confiança do token externo serão ignorados e um aviso será emitido: "não foi possível alterar a confiança no certificado".



Um certificado duplicado em um token interno pode ser excluído, se desejado.



Para remover um certificado de qualquer token, use o seguinte comando: 



$certutil -D [-d < NSS>] -n <nickname->


Por exemplo, para remover o certificado com o rótulo (CKA_LABEL) "User1" do token RuTokenECP20, basta executar o seguinte comando: 



$certutil -D -d /home/a513/tmp/TEST_NSS -n "RuTokenECP20:1"


Quando você exclui um certificado, sua chave privada não é excluída (se houver, é claro). Para excluir uma chave privada, você precisa executar um comando do formulário: 



$certutil -F [-k < >] [-d < NSS>] -n <nickname->, 
< > := rsa|dsa|ec


Agora que temos um repositório NSS, tokens com certificados pessoais, podemos trabalhar com uma assinatura eletrônica.



Formação e verificação de assinatura eletrônica



Existem três utilitários para trabalhar com assinaturas eletrônicas no pacote NSS.



O utilitário p7sign é usado para gerar uma assinatura eletrônica: 



$pksign -k <nickname  > [-d < NSS>] [-e] [-i <  >] [-o <   >], 
<nickname  > := [< >:]<CKA_LABEL>


Infelizmente, o utilitário gera uma assinatura sem referência ao momento de sua formação. Mas isso é facilmente corrigido. Basta adicionar uma linha à função SignFile no utilitário p7sign.c com uma chamada à função para adicionar o tempo de geração da assinatura: 



SignFile(FILE *outFile, PRFileDesc *inFile, CERTCertificate *cert,
         PRBool encapsulated)
{  
. . . 
    /* XXX Need a better way to handle that usage stuff! */
    cinfo = SEC_PKCS7CreateSignedData(cert, certUsageEmailSigner, NULL,
                                      SEC_OID_SHA1,
                                      encapsulated ? NULL : &digest,
                                      NULL, NULL);
    if (cinfo == NULL)
        return -1;
/*   */
    SEC_PKCS7AddSigningTime(cinfo);

    if (encapsulated) {
        SEC_PKCS7SetContent(cinfo, (char *)data2sign.data, data2sign.len);
    }
 . . . 
}


Agora será gerada uma assinatura eletrônica no formato CAdes-BES.



É aceito no NSS que o certificado e sua chave privada sejam armazenados no mesmo token e seus rótulos (CKA_LABEL), bem como CKA_ID, sejam os mesmos. Conseqüentemente, o apelido da chave privada e o apelido do próprio certificado são os mesmos. Lembre-se de que a presença de uma chave privada em um certificado pode ser encontrada pelo valor "u, u, u" dos atributos de confiança do certificado visualizado (comando certutil -L).



Por padrão, o utilitário p7sign gera uma assinatura separada. Se uma assinatura anexada for necessária, o parâmetro "-e" deve ser especificado. Deve-se ter em mente que a assinatura não será gerada se no armazenamento NSS, em seu token interno, não houver uma cadeia de certificados raiz para o certificado do signatário ou se os atributos de confiança para eles não estiverem definidos.



O utilitário p7verify é usado para verificar a assinatura eletrônica: 



$p7verify -c < > -s <  > [-d < NSS>] [-u < >]


O parâmetro "-u" é de interesse. Ele instrui a verificar o tipo de certificado do signatário e se ele não corresponder ao tipo especificado, a assinatura será invalidada.



O valor <uso do certificado> pode ter os seguintes valores:

0 - certUsageSSLClient

1 - certUsageSSLServer

2 - certUsageSSLServerWithStepUp

3 - certUsageSSLCA

4 - certUsageEmailSigner

5 - certUsageEmailRecipient

6 - certUsageObjectSigner

7 - certUsageUserCertImport

8 - certUsageVerifyCA

9 - certUsageProtectedObjectSigner

10 - certUsageStatusResponder

11 - certUsageAnyCA

12 - certUsageIPsec


O padrão é certUsageEmailSigner (4).

O utilitário p7content permite obter informações sobre a hora de assinatura do documento, quem o assinou e o endereço de e-mail do assinante. Se a assinatura foi anexada, o próprio conteúdo que foi assinado também é recuperado.



O utilitário p7content tem o seguinte formato: 



$p7content [-d < NSS>] [-i <  >] [-o < >]


Por exemplo: 



$ p7content -d "sql:/home/a513/tmp/TEST_NSS" -i "/home/a513/DATE_NSS.txt.p7s"
Content printed between bars (newline added before second bar):

#     ,    "-" ()
#     
---------------------------------------------
  NSS

---------------------------------------------
Content was not encrypted.
Signature is valid.
The signer's common name is  1
The signer's email address is user1@mail.ru
Signing time: Fri Jul 17 10:00:45 2020
There were certs or crls included.
$


Esses são apenas alguns dos utilitários incluídos no pacote NSS. Naturalmente, o OpenSSL e o NSS têm utilitários (ou comandos) que permitem criar solicitações de certificado e emitir certificados, ou seja, é possível implantar um CA totalmente funcional, uma vez que é feito usando o openssl. Você pode aumentar o servidor tls com o utilitário selfserv (análogo do openssl s_server) e usar o cliente tls tstclnt (análogo do openssl s-client) e muito, muito mais.



A propósito, a lista de ciphersuites no NSS pode ser obtida com o utilitário listsuites. No OpenSSL, o comando openssl ciphers serve a esse propósito. O mapeamento de nomes de conjuntos de criptografia OpenSSL para nomes de conjuntos de criptografia IANA pode ser encontrado aqui .



Na verdade, OpenSSL e NSS são dois lados (dois tipos de interfaces para os mesmos protocolos e padrões) da mesma moeda - a infraestrutura de chave pública.



Se houver interesse neste tópico, a história continuará.



Concluindo, eu também gostaria de me alongar sobre o shell gráfico para NSS. Existem vários shells gráficos para OpenSSL. Observamos apenas dois deles - XCA e CAFL63 .



GUI Guinsspy para o pacote NSS



A primeira pergunta é em que desenvolver? Foi decidido em Python.



A segunda questão é em que escrever uma interface gráfica? A resposta é Tkinter.



O gui foi originalmente desenvolvido no PAGE . Mas então eles se afastaram dele. Mas o contexto permaneceu.



A funcionalidade do utilitário é baseada nos utilitários e comandos discutidos acima. Além deles, foi adicionada outra função “Criar solicitação de certificado”, que é baseada no comando “certutil -R”:







foi decidido usar o tema Breeze para python3 e o tema Arc para python2 como tema para os widgets, já que este último não tem o tema Breeze. Para fazer isso, você precisa instalar um pacote com temas para pythona: 



$pip install ttkthemes


Também precisamos do pacote fsb795 para trabalhar com certificados: 



$pip install fsb795


Os utilitários NSS nos quais o guinsspy se baseia, muitas vezes pedem senhas ou PINs através do console. A única maneira de interagir com eles por meio da GUI é usando o pacote pexpect: 



$pip install pexpect


Como um exemplo de uso do pacote pexpect, aqui está o código para importar um contêiner PKCS # 12:



importP12 
def importP12(frameManager):
    global readpw
    global filename
    tokname = frameManager.STCombobox1.get()
    fp12 = frameManager.SEntry1.get()
    if (fp12 == () or fp12 == ''):
        tkMessageBox.showinfo(title="  PKCS#12", message='  \n')
        return (-1, "", "")
    filename = fp12
    if sys.platform != "win32":
        cmd_import_p12 = '"' + patch_win + 'pk12util" -i "' + fp12 + '" -h "' + tokname + '"  -d "' + NSSname + '"'
        id = pexpect.spawn(cmd_import_p12, timeout=1)
    else:
        cmd_import_p12 = '"' + patch_win + 'pk12util" -i "' + fp12 + '" -h "'  + tokname + '"  -d "' + NSSname + '"'
        id = pexpect.popen_spawn.PopenSpawn(cmd_import_p12, timeout=10)
    while(True):
        ret = id.expect(["Enter Password or Pin", "Enter password for PKCS12 file",pexpect.EOF, pexpect.TIMEOUT])
        if (ret == 0 or ret == 1):
            root.update()
            if (ret == 0):
                password('', tokname, 0)
                pasP11 = readpw
            else:
                password('', os.path.basename(fp12), 1)
                pasP12 = readpw
            if (readpwok == 0):
                if sys.platform != "win32":
                    id.close()
                return (-3, fp12, "")
            if sys.platform != "win32":
                id.send(readpw)
                id.send("\r")
            else:
                id.sendline(readpw)
            lseek = 1
        elif (ret == 2):
            break
        elif (ret == 3):
            break
            if sys.platform != "win32":
                id.close()
            return (-1, fp12, "")
    if sys.platform != "win32":
        res = id.before.decode('UTF-8')
        id.close()
    else:
        res = id.before.decode('UTF-8')
    if (res.find("PKCS12 IMPORT SUCCESSFUL") != -1):
        ret = 0
    elif (res.find("SEC_ERROR_BAD_PASSWORD") != -1):
        ret = -1
        return (ret, fp12, "")
    else:
        ret = -2
    return (ret, fp12, res)




Um loop infinito (enquanto (True) :) no procedimento aguarda a ocorrência de um dos quatro eventos: 



ret = id.expect(["Enter Password or Pin", "Enter password for PKCS12 file",pexpect.EOF, pexpect.TIMEOUT])


O primeiro evento está associado a um convite para inserir uma senha ou PIN ("Inserir senha ou PIN").

Quando isso ocorrer, será exibida na tela uma janela para inserção de um código PIN (janela à esquerda na captura de tela):







O segundo evento está associado à inserção da senha do container PKCS # 12 ("Digitar senha para arquivo PKCS12"). Quando isso ocorrer, a tela exibirá uma janela para digitação da senha do arquivo com o container PKCS # 12 (janela à direita na imagem).



O terceiro evento está associado ao encerramento do utilitário pk12util (pexpect.EOF) e o quarto evento está associado ao encerramento do utilitário por tempo limite (pexpect.TIMEOUT).



O código-fonte do guinsspy pode ser encontrado aqui . O kit de distribuição do pacote NSS para trabalhar com tokens PKCS # 11 com criptografia russa para a plataforma Linux x86_64 pode ser encontrado lá.



Para testar os tokens criptográficos russos, copie a pasta NSS_GOST_3.52.1_Linux_x86_64 para o seu diretório inicial. Crie um script guinsspy_gost.sh: 



export LD_LIBRARY_PATH=~/NSS_GOST_3.52.1_Linux_x86_64:$LD_LIBRARY_PATH
export PATH=~/NSS_GOST_3.52.1_Linux_x86_64:$PATH
python3 guinsspy.py


Agora execute este script e trabalhe com tokens russos.

Se você não tiver um token com criptografia russa em mãos, vá para a guia "Criar token de SW / nuvem", que lhe dirá como criar um token de software em seu computador ou conectar-se a um token de nuvem :







E, finalmente, capturas de tela de criação de uma







solicitação de certificado: Solicitação recebida pode ser transferido para CAFL63 , emitido lá um certificado, instalado no token em que a chave privada foi criada. E então use este certificado, por exemplo, para assinar documentos.


More articles:


All Articles