Back home

ARTES #010

ARTES #010

ARTS é uma atividade iniciada por 由左耳朵耗子--陈皓: Faça pelo menos uma pergunta sobre o algoritmo leetcode toda semana, leia e comente pelo menos um artigo técnico em inglês, aprenda pelo menos uma habilidade técnica e compartilhe um artigo com opiniões e pensamentos. (Ou seja, Algoritmo, Revisão, Dica e Compartilhamento são chamados de ARTS) e persistem por pelo menos um ano.

ARTES 010

Este é o artigo 10

Pergunta sobre algoritmo de algoritmo

Eu fiz duas perguntas sobre algoritmos esta semana

Pergunta 1

Pergunta do algoritmo leetcode 767.Reorganizar String: Dificuldade: Moderada


Given a string S, check if the letters can be rearranged so that two characters that are adjacent to each other are not the same.

If possible, output any possible result.  If not possible, return the empty string.

Example 1:

Input: S = "aab"
Output: "aba"
Example 2:

Input: S = "aaab"
Output: ""
Note:

S will consist of lowercase letters and have length in range [1, 500].

Minha ideia de resolver o problema, a primeira coisa que pensei foi que se o número de uma determinada letra ultrapassar a metade do comprimento de S, então “” deverá ser retornado. A questão requer apenas letras minúsculas, então pensei primeiro em calcular o número de cada caractere da string S, e depois pensei em ordenar pelo número de caracteres. Finalmente, tive que considerar algumas condições de contorno, complexidade de tempo e complexidade de espaço. A implementação específica é a seguinte. O tempo de execução do LeetCode é 0ms e a complexidade do tempo é O(n).


char* reorganizeString(char* S) {
    int len = strlen(S);
    
    //计算S中每个字母的个数
    //Calculate the number of  letters in S
    int* charCount = (int*)malloc(sizeof(int) * 26);
    memset(charCount, 0, sizeof(int) * 26);
    for (int i = 0; i < len; i++) {
        int index = S[i] - 97;
        charCount[index]++;
    }
    
    //如果某一个字母的个数超过S长度的一半,直接返回""
    //If the number of letters is more than half the length of S, directly return  ""
    for (int i = 0; i < 26; i++) {
        int index  = charCount[i];
        if (index > len/2 + len%2) {
            return "";
        }
    }
   
    
    //"排序",这里的排序是按字母的个数排序,字母多的放到前面。比如S="dddbbbbffkkkkkk",那么排序后的orderS是"kkkkkkbbbbdddff"
    //"sorting",The sorting here is sorted by the number of letters, and put the more letters in front,eg:if S="dddbbbbffkkkkkk",so orderS is "kkkkkkbbbbdddff"
    char * orderS = (char*)malloc(sizeof(char*) * len);
    int count = 0;
    for (int i = 0; i < 26; i++) {
        int  sortingNum = charCount[i];
        int maxIndex = i;
        for (int j =0; j < 26; j++) {
            if (sortingNum < charCount[j] ) {
                sortingNum = charCount[j];
                maxIndex = j;
            }
        }
        for (int j = 0; j < sortingNum; j++) {
            orderS[count++] = maxIndex + 97;
        }
        charCount[maxIndex] = 0;
    }
    
    //打乱顺序 比如orderS是'bbbc ccdd',打乱后就是bcbcbdcd
    //reorganizeString eg: orderS is 'bbbc ccdd', reorganizeString is bcbcbdcd
    int max = len/2;
    int mid = max+ len%2;
    for (int i =0; i < max; i++) {
        S[2*i] =orderS[i];
        S[2*i+1] =orderS[mid+i];
    }
    if (len%2) {
        S[len -1] = orderS[max];
    }
    free(orderS);
    free(charCount);
    
    return S;
}

Pergunta 2

Pergunta do algoritmo leetcode 541. String reversa II: Dificuldade: Fácil


Given a string and an integer k, you need to reverse the first k characters for every 2k characters counting from the start of the string. If there are less than k characters left, reverse all of them. If there are less than 2k but greater than or equal to k characters, then reverse the first k characters and left the other as original.
Example:
Input: s = "abcdefg", k = 2
Output: "bacdfeg"
Restrictions:
The string consists of lower English letters only.
Length of the given string and k will in the range [1, 10000]

Esta questão é relativamente simples, basta considerar mais algumas situações.

void ReverseString(char* str,int min,int max) {
    int i = min;
    int j = max;
    while (i < j) {
        char temp = * (str + i);
        * (str + i) = * (str + j);
        * (str + j)  = temp;
        
        i++;
        j--;
    }
}

char* reverseStr(char* s, int k) {
    u_long strlength =  strlen(s);
    if ( k == 0) {
        ReverseString(s,0,strlength-1);
        
    }
    else {
        u_long count = strlength/(2*k);
        for (int i = 0; i < count; i++) {
            ReverseString(s,(2*k)*i,(2*k)*i + k-1);
        }
        u_long count_1 = strlength%(2*k);
        if (count_1 > 0) {
            if(count_1<k){//剩余少于 k 个字符
                ReverseString(s,strlength- count_1,strlength -1);
            }
            else{//小于 2k 但大于或等于 k 个字符
                ReverseString(s,strlength- count_1,strlength- count_1  + k -1);
            }
        } 
    }
    return s;
}

Revisão

Este artigo vem de: https://medium.freecodecamp.org/how-to-become-a-git-expert-e7c38bf54826

Como se tornar um especialista em Git Como se tornar um especialista em Git

“fotografia em lapso de tempo de um homem parado ao lado da estrada e da ponte durante o dia” por Ahsan Avi no Unsplash Fotografia em lapso de tempo de pessoas paradas na beira da estrada e na ponte durante o dia, por Ahsan Avi no Unsplash

Cometi um erro no meu commit, como faço para corrigir isso? Cometi um erro ao enviar o código, como devo corrigi-lo?

Meu histórico de commits está uma bagunça, como posso torná-lo mais organizado? Meu histórico de commits de código está uma bagunça, como faço para mantê-lo organizado?

Se você já teve as dúvidas acima, então este post é para você. Esta postagem cobre uma lista de tópicos que farão de você um especialista em Git. Se você já teve as dúvidas acima, este artigo é para você. Este artigo cobre uma variedade de tópicos que farão de você um especialista em Git.

Se você não conhece os fundamentos do Git, clique aqui para conferir meu blog sobre os fundamentos do Git. É necessário que você conheça o básico do Git para aproveitar melhor este artigo. Se você não conhece os fundamentos do Git, clique aqui para ver meu blog de fundamentos do Git. Compreender os fundamentos do Git é necessário para aproveitar ao máximo este artigo.

“placa de cerâmica quebrada no chão” por chuttersnap no Unsplash Placa de cerâmica quebrada no chão por chuttersnap no Unsplash

Cenário 1 Cenário 1

Digamos (supondo) que você enviou vários arquivos e percebeu que a mensagem de commit inserida não está clara. Agora você deseja alterar a mensagem de commit. Para fazer isso você pode usar git commit --amend

Digamos que você submeta vários arquivos e perceba que a mensagem de commit inserida não está realmente clara. Agora a mensagem de commit precisa ser alterada. Para fazer isso você pode usar git commit -amend

git commit --amend -m “New commit message”

Cenário 2 Cenário 2

Digamos que você queira enviar seis arquivos, mas, por engano, acaba enviando apenas cinco arquivos. Você pode pensar que pode criar um novo commit e adicionar o sexto arquivo a esse commit.

Digamos que você queira enviar 6 arquivos, mas por engano acaba enviando apenas 5 arquivos. Você pode pensar que poderia criar um novo commit e adicionar um sexto arquivo a esse commit.

Não há nada de errado com essa abordagem. Mas, para manter um histórico de commits organizado, não seria melhor se você pudesse de alguma forma adicionar esse arquivo ao seu commit anterior? Isso também pode ser feito através do git commit --amend:

Não há nada de errado com essa abordagem. No entanto, para manter um histórico de commits organizado, não seria melhor se você pudesse de alguma forma adicionar esse arquivo ao commit anterior? Isso pode ser conseguido com ’ git commit -amend ':

git add file6
git commit --amend --no-edit

--no-edit significa que a mensagem de commit não muda.

Cenário 3 Cena 3

Sempre que você faz um commit no Git, o commit tem um nome de autor e um e-mail de autor vinculados a ele. Geralmente, ao configurar o Git pela primeira vez, você configura o nome do autor e o email. Você não precisa se preocupar com os detalhes do autor de cada commit.

Sempre que você executa um commit no Git, o commit tem um nome e e-mail do autor. Normalmente, ao configurar o Git pela primeira vez, você configura seu nome de autor e e-mail. Você não precisa se preocupar com os detalhes do autor de cada envio.

Dito isto, é possível que para um projeto específico você queira usar um ID de e-mail diferente. Você precisa configurar o ID de e-mail desse projeto com o comando: Dito isto, você pode querer usar um ID de e-mail diferente para um projeto específico. Você precisa configurar o ID de e-mail do projeto usando o seguinte comando:

git config user.email “your email id”

Digamos que você esqueceu de configurar o email e já fez seu primeiro commit. Amend também pode ser usado para alterar o autor do seu commit anterior. O autor do commit pode ser alterado usando o seguinte comando:

Digamos que você esqueceu de configurar seu email e já fez seu primeiro commit. “Alterar” também pode ser usado para alterar o autor do seu envio anterior. O autor de um commit pode ser alterado usando:

git commit --amend --author "Author Name <Author Email>"
Ponto a nota

Use o comando amend somente em seu repositório local. Usar amend para o repositório remoto pode criar muita confusão. Use o comando “amend” apenas em repositórios locais. Usar o amend com repositórios remotos pode causar muita confusão.

Meu histórico de commits está uma bagunça. Como faço para lidar com isso? Meu histórico de commits está uma bagunça. Como faço para lidar com isso?

Digamos que você esteja trabalhando em um trecho de código. Você sabe que o código levará aproximadamente dez dias para ser concluído. Dentro desses dez dias, os outros desenvolvedores também enviarão o código para o repositório remoto. Digamos que você esteja trabalhando em um trecho de código. Veja, o código leva cerca de 10 dias para ser concluído. Durante esses dez dias, outros desenvolvedores também enviarão código para o repositório remoto.

É uma boa prática manter o código do repositório local atualizado com o código do repositório remoto. Isso evita muitos conflitos de mesclagem posteriormente, quando você levanta uma solicitação pull. Então você decide extrair as alterações do repositório remoto uma vez a cada dois dias.É uma boa prática manter o código do repositório local atualizado com o código do repositório remoto. Isso evita muitos conflitos de mesclagem ao fazer solicitações pull no futuro. Então você decide extrair alterações do repositório remoto a cada dois dias.

Cada vez que você extrai o código do repositório remoto para o repositório local, um novo commit de mesclagem é criado em seu repositório local. Isso significa que seu histórico de commits locais terá muitos commits de mesclagem, o que pode fazer as coisas parecerem confusas para o revisor. Cada vez que o código é extraído do repositório remoto para o repositório local, um novo commit de mesclagem é criado no repositório local. Isso significa que seu histórico de commits locais terá muitos commits de mesclagem, o que confundirá os revisores.

Esta é a aparência do histórico de commits em seu repositório local. Esta é a aparência do histórico de commits em seu repositório local.

Como você faz o histórico de commits parecer mais organizado? É aqui que o rebase vem em socorro. Como posso fazer com que meu histórico de commits pareça mais limpo? É aqui que o rebase vem em socorro.

O que é rebase? Deixe-me explicar isso através de um exemplo.

Este diagrama mostra os commits no branch de lançamento e no branch de recursos

  1. A ramificação Release possui três commits: Rcommit1, Rcommit2 e Rcommit3.
  2. Você criou sua ramificação Feature a partir da ramificação Release quando ela tinha apenas um commit, que é Rcommit1.
  3. Você adicionou dois commits ao branch Feature. Eles são Fcommit1 e Fcommit2.
  4. Seu objetivo é levar os commits do branch Release para o branch Feature.
  5. Você usará o rebase para fazer isso.
  6. Deixe o nome da ramificação Release ser release e o nome da ramificação Feature ser feature.
  7. O rebase pode ser feito usando os seguintes comandos:

Este diagrama mostra commits em ramificações de lançamento e ramificações de recursos

  1. O branch Release possui três commits: Rcommit1, Rcommit2 e Rcommit3.
  2. Quando o branch Release tem apenas um commit (ou seja, Rcommit1), você cria o branch Feature a partir do branch release.
  3. Você adicionou dois commits ao branch Feature. Eles são Fcommit1 e Fcommit2.
  4. Seu objetivo é mesclar os commits do branch Release com o branch Feature.
  5. Você precisa usar o rebase para fazer isso.
  6. Deixe o nome da ramificação Release ser release e o nome da ramificação Feature ser feature.
  7. Você pode usar o seguinte comando para rebase:
git checkout feature
git rebase release

Rebase

Durante o rebase, seu objetivo é garantir que a ramificação Feature obtenha o código mais recente da ramificação Release.

O rebase tenta adicionar cada commit, um por um, e verifica se há conflitos. Isso parece confuso?

Deixe-me explicar com a ajuda de um diagrama.

Isso mostra o que o rebase realmente faz internamente:

Rebase Ao fazer o rebase, seu objetivo é garantir que a ramificação Feature obtenha o código mais recente da ramificação Release.

rebase tenta adicionar cada commit um por um e verifica se há conflitos. Parece confuso?

Deixe-me explicar com um diagrama.

Isso mostra o que o rebase realmente faz internamente:

Passo 1

  1. No momento em que você executa o comando, a ramificação Feature é apontada para o início da ramificação Release.
  2. Agora a ramificação Feature tem três commits: Rcommit1, Rcommit2 e Rcommit3.
  3. Você pode estar se perguntando o que aconteceu com Fcommit1 e Fcommit2.
  4. Os commits ainda estão lá e serão utilizados nas etapas abaixo. Etapa 2
  5. Agora o Git tenta adicionar Fcommit1 ao branch Feature.
  6. Se não houver conflito, Fcommit1 será adicionado após Rcommit3
  7. Se houver um conflito, o Git irá notificá-lo e você terá que resolver o conflito manualmente. Etapa 3
  8. Depois que o Fcommit1 for adicionado, o Git tentará adicionar o Fcommit2.
  9. Novamente, se não houver conflito, Fcommit2 será adicionado após Fcommit1 e o rebase será bem-sucedido.
  10. Se houver um conflito, o Git irá notificá-lo e você terá que resolvê-lo manualmente.
  11. Após a conclusão de todo o rebase, você notará que a ramificação Feature possui Rcommit1, Rcommit2, Rcommit3, Fcommit1 e Fcommit2.

Passo 1

  1. Ao executar o comando, a ramificação do recurso aponta para o início da ramificação de lançamento.
  2. A ramificação do recurso agora possui três commits: Rcommit1, Rcommit2 e Rcommit3.
  3. Você pode estar se perguntando o que aconteceu com Fcommit1 e Fcommit2.
  4. O commit ainda existe e será utilizado nas próximas etapas. Etapa 2
  5. Agora o Git tenta adicionar Fcommit1 ao branch de recurso.
  6. Se não houver conflito, adicione Fcommit1 após Rcommit3
  7. Se houver um conflito, o Git irá notificá-lo e você deverá resolver o conflito manualmente. Etapa 3
  8. Após adicionar Fcommit1, o Git tentará adicionar Fcommit2.
  9. Da mesma forma, se não houver conflito após Fcommit1, adicione Fcommit2 após Fcommit1 e o rebase será bem-sucedido.
  10. Se ocorrer um conflito, o Git irá notificá-lo e você deverá resolvê-lo manualmente.
  11. mostrado. Após concluir todo o rebase, você notará que as ramificações do Feature são Rcommit1, Rcommit2, Rcommit3, Fcommit1 e Fcommit2.

Pontos a serem observados

  1. Tanto Rebase quanto Merge são úteis no Git. Um não é melhor que o outro.
  2. No caso de uma mesclagem você terá um commit de mesclagem. No caso de um rebase, não há commit extra como um commit de mesclagem.
  3. Uma prática recomendada é usar os comandos em pontos diferentes. Use rebase ao atualizar seu repositório de código local com o código mais recente do repositório remoto. Use merge quando estiver lidando com solicitações pull para mesclar a ramificação Feature com a ramificação Release ou Master.

Nota

  1. No Git, tanto Rebase quanto Merge são úteis. Um não é melhor que o outro.
  2. Em caso de mesclagem, você terá um commit de mesclagem. No caso de rebase, não há commits extras como commits de mesclagem.
  3. A melhor prática é usar comandos diferentes em locais diferentes. Use rebase ao atualizar seu repositório de código local com o código mais recente do repositório remoto. Ao processar uma solicitação pull, use merge para mesclar o branch do recurso de volta ao branch de lançamento ou branch master.

Parabéns

Agora você é um especialista em Git 😃Neste post você aprendeu sobre:

  • alterando commits
  • rebase Ambos são conceitos muito úteis. Explore o mundo do Git para aprender ainda mais.

Parabéns

Agora você é um especialista em Git

Neste artigo você aprendeu:

*Modificar e enviar *Rebase Ambos os conceitos são úteis. Explore o mundo do Git e aprenda mais.

Sobre o autor Adoro tecnologia e acompanho os avanços da área. Também gosto de ajudar outras pessoas com meu conhecimento de tecnologia.

Sinta-se à vontade para se conectar comigo em minha conta do LinkedIn https://www.linkedin.com/in/aditya1811/

Você também pode me seguir no Twitter https://twitter.com/adityasridhar18

Outras postagens minhas Uma introdução ao Git

Como usar o Git com eficiência

DICAS:

Como usar itms-services para instalar o servidor de distribuição ipa empacotado com certificados corporativos

O processo de configuração de um servidor é relativamente simples. Você mesmo pode usar o Baidu ou o Google. Eu uso nginx no Mac

O servidor que uso é Mac Nginx. A configuração é muito simples e existem muitos tutoriais na Internet. A chave agora é como habilitar https.

Após o sistema IOS7.1, se você quiser usar um certificado corporativo (US$ 299) para instalar o ipa online através de itms-services, você deve usar o protocolo https.

nginx permite configuração https: https://www.jianshu.com/p/fe0fadb38600、

Há uma etapa de reinicialização no artigo agora: serviços de fermentação reiniciam o nginx

Recomenda-se habilitar o log de erros no arquivo de configuração do nginx, para que se houver erros durante o processo de inicialização, você possa visualizá-los diretamente. Alguns erros não podem ser vistos no terminal. Por exemplo, quando eu uso brew services restart nginx para reiniciar, ele solicita sucesso.

Stopping `nginx`... (might take a while)
==> Successfully stopped `nginx` (label: homebrew.mxcl.nginx)
==> Successfully started `nginx` (label: homebrew.mxcl.nginx)

Mas na verdade falhou.

Mais tarde vi no errlog: bind() to 0.0.0.0:443 failed (13: Permissão negada)

Precisa usar: sudo brew services reinicia o nginx para iniciar

Existe um conceito aqui que requer CA, explicação sobre CA: https://www.cnblogs.com/handsomeBoys/p/6556336.html、https://www.jianshu.com/p/57066821b863 Simplificando, ativar o https requer um certificado. Este certificado precisa ser aplicado a um site oficial de terceiros ou você mesmo pode criá-lo. É claro que os sites https executados on-line devem ser processados ​​como sites oficiais de terceiros. Porque os certificados autoconstruídos exigem que os usuários os instalem manualmente e os navegadores não confiam neles. Não faria sentido https se alguém pudesse criar um certificado. Mas nosso objetivo atual é utilizá-lo na LAN da empresa, por isso usamos um certificado autoconstruído. O certificado autoconstruído precisa ser instalado manualmente pelo usuário.

O artigo abaixo sobre as configurações do itms-services também é muito claro: http://www.cnblogs.com/feiyiban588/p/5788310.html https://blog.csdn.net/RazerTang/article/details/46898051/

Você também pode fazer uma CA seguindo estas etapas:

Faça sua própria CA

1. Introdução

Antes, meu blog suportava https e usava um certificado gratuito de um ano emitido pela StartCom CA. StartCom é uma CA confiável. Seu certificado raiz é confiável para vários sistemas operacionais e navegadores, portanto, os certificados emitidos por ele também serão confiáveis.

Recentemente, criei um programa de upload e download de pacotes iOS ipa, que também requer o uso de links https. Verifiquei online e descobri que posso assinar o certificado sozinho, então coloquei-o em prática. Aqui estão as etapas detalhadas.

Recomendo particularmente o site abaixo, que fala sobre isso detalhadamente.

https://jamielinux.com/docs/openssl-certificate-authority/index.html

Existem algumas funções no tutorial que você só precisa entender, mas não precisamos usá-las, então removi algumas etapas para torná-las mais simples e fáceis de usar.

2. CA

Ao atuar como CA, você usa o comando openssl para gerar seu próprio certificado raiz e permitir que os usuários o instalem e confiem nele. Assim, todos os certificados assinados com este certificado raiz também poderão ser confiáveis.

Portanto, como CA, devemos primeiro gerar nosso próprio certificado raiz ca.cert.pem, e a geração do certificado raiz requer ca.key.pem.

começar Crie a pasta /root/ca. Todas as operações da CA serão realizadas nesta pasta.


 # mkdir /root/ca
    # cd /root/ca
    # mkdir certs crl newcerts private
    # chmod 700 private
    # touch index.txt
    # echo 1000 > serial
    # touch openssl.cnf
    

/root/ca: pasta CA

/root/ca/certs: O local onde o certificado recém-assinado e o certificado raiz são armazenados

/root/ca/crl: Local de armazenamento do arquivo de solicitação de certificado

/root/ca/newcerts: O local onde o certificado recém-assinado está armazenado, que é um backup de /root/ca/certs

/root/ca/private: local de armazenamento ca.key.pem, não o perca

/root/ca/index.txt: registro de assinatura do certificado

/root/ca/serial: O número de série da próxima assinatura do certificado, salvo em index.txt

Copie o seguinte conteúdo para /root/ca/openssl.cnf

# OpenSSL root CA configuration file.
# Copy to `/root/ca/openssl.cnf`.

[ ca ]
# `man ca`
default_ca = CA_default

[ CA_default ]
# Directory and file locations.
dir               = /root/ca
certs             = $dir/certs
crl_dir           = $dir/crl
new_certs_dir     = $dir/newcerts
database          = $dir/index.txt
serial            = $dir/serial
RANDFILE          = $dir/private/.rand

# The root key and root certificate.
private_key       = $dir/private/ca.key.pem
certificate       = $dir/certs/ca.cert.pem

# For certificate revocation lists.
crlnumber         = $dir/crlnumber
crl               = $dir/crl/ca.crl.pem
crl_extensions    = crl_ext
default_crl_days  = 30

# SHA-1 is deprecated, so use SHA-2 instead.
default_md        = sha256

name_opt          = ca_default
cert_opt          = ca_default
default_days      = 3750
preserve          = no
policy            = policy_strict

[ policy_strict ]
# The root CA should only sign intermediate certificates that match.
# See the POLICY FORMAT section of `man ca`.
countryName             = match
stateOrProvinceName     = match
organizationName        = match
organizationalUnitName  = optional
commonName              = supplied
emailAddress            = optional

[ policy_loose ]
# Allow the intermediate CA to sign a more diverse range of certificates.
# See the POLICY FORMAT section of the `ca` man page.
countryName             = optional
stateOrProvinceName     = optional
localityName            = optional
organizationName        = optional
organizationalUnitName  = optional
commonName              = supplied
emailAddress            = optional

[ req ]
# Options for the `req` tool (`man req`).
default_bits        = 2048
distinguished_name  = req_distinguished_name
string_mask         = utf8only

# SHA-1 is deprecated, so use SHA-2 instead.
default_md          = sha256

# Extension to add when the -x509 option is used.
x509_extensions     = v3_ca

[ req_distinguished_name ]
# See <https://en.wikipedia.org/wiki/Certificate_signing_request>.
countryName                     = Country Name (2 letter code)
stateOrProvinceName             = State or Province Name
localityName                    = Locality Name
0.organizationName              = Organization Name
organizationalUnitName          = Organizational Unit Name
commonName                      = Common Name
emailAddress                    = Email Address

# Optionally, specify some defaults.
countryName_default             = CN
stateOrProvinceName_default     = JiangSu
localityName_default            = NanJing
0.organizationName_default      = SIYOU325
organizationalUnitName_default  = SIYOU325
emailAddress_default            = webmaster@siyou325.com

[ v3_ca ]
# Extensions for a typical CA (`man x509v3_config`).
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true
keyUsage = critical, digitalSignature, cRLSign, keyCertSign

[ v3_intermediate_ca ]
# Extensions for a typical intermediate CA (`man x509v3_config`).
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true, pathlen:0
keyUsage = critical, digitalSignature, cRLSign, keyCertSign

[ usr_cert ]
# Extensions for client certificates (`man x509v3_config`).
basicConstraints = CA:FALSE
nsCertType = client, email
nsComment = "OpenSSL Generated Client Certificate"
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
keyUsage = critical, nonRepudiation, digitalSignature, keyEncipherment
extendedKeyUsage = clientAuth, emailProtection

[ server_cert ]
# Extensions for server certificates (`man x509v3_config`).
basicConstraints = CA:FALSE
nsCertType = server
nsComment = "OpenSSL Generated Server Certificate"
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer:always
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth

[ crl_ext ]
# Extension for CRLs (`man x509v3_config`).
authorityKeyIdentifier=keyid:always

[ ocsp ]
# Extension for OCSP signing certificates (`man ocsp`).
basicConstraints = CA:FALSE
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
keyUsage = critical, digitalSignature
extendedKeyUsage = critical, OCSPSigning

Para uma explicação detalhada, você pode ver o link acima (realmente recomendado). Aqui vou escolher os mais importantes.

dir = /root/ca: Isso precisa ser alterado para a pasta CA acima

política = política_strict: Use a política estrita para assinar o certificado CA

paísName_default = CN

0.nomedaorganização_default = SIYOU325 CA

Esses dois são os nomes dos países e das organizações, que serão exibidos no certificado gerado. Basta assinar um certificado CA. Definimos apenas esses dois valores e deixamos os demais vazios.

[v3_ca]: Esta configuração é necessária para assinar o certificado CA

[server_cert]: Isso é necessário para assinar o próximo certificado do servidor

Gerar chave raiz

# cd /root/ca
# openssl genrsa -aes256 -out private/ca.key.pem 4096

输入两次密码siyou325123456,这个是很重要的密码,设置严格点。

# chmod 400 private/ca.key.pem

Gerar certificado raiz

# cd /root/ca
# openssl req -config openssl.cnf \
      -key private/ca.key.pem \
      -new -x509 -days 7500 -sha256 -extensions v3_ca \
      -out certs/ca.cert.pem

根据提示输入key的密码:siyou325123456
然后一值回车下去,使用默认值

# chmod 444 certs/ca.cert.pem

-dias 7300: Válido por 20 anos

Neste ponto, ca.key.pem (chave raiz) e ca.cert.pem (certificado raiz) foram gerados. Os caminhos são os seguintes

/root/ca/private/ca.key.pem
/root/ca/certs/ca.cert.pem

Neste ponto, a geração do certificado raiz está concluída.

A senha de ca.key.pem é siyou325123456, que é muito importante e precisa ser bem salva.

ca.cert.pem é o certificado raiz. Ele precisa ser enviado ao usuário para que ele possa instalá-lo e confiá-lo, para que todos os certificados que assinamos com este certificado possam ser confiáveis ​​no futuro.

3. Gerar certificado de servidor

O trabalho da função CA foi concluído. Agora usamos a função de usuário para gerar um certificado de servidor que pode ser usado pelo Tomcat e nginx.

Suponha aqui que o nome de domínio ou endereço IP do nosso site seja 127.0.0.1, então crie a pasta 127.0.0.1 no diretório do mesmo nível de ca e gere o certificado do servidor neste diretório.

# mkdir /root/127.0.0.1
# cd /root/127.0.0.1

# openssl genrsa -out server.key 2048
# openssl req -new -key server.key -out server.csr

会出现提示,简单点,除了下面几个,其他的都按回车就可以了。
Country Name输入:CN
Common Name输入域名或ip:127.0.0.1
A challenge password输入:server123456

openssl genrsa -out server.key 2048: 2048 após este comando representa o número de bits de criptografia. Use estritamente 4096. Por exemplo, o certificado raiz acima usa isso. Geralmente, 2048 e 1024 são suficientes. Quanto maior o valor, maior será o tempo de espera do link https.

Neste ponto, nossa chave de servidor (server.key) e solicitação de certificado (server.csr) são geradas.

Em seguida, copie server.csr para ca/crl e renomeie-o para 127.0.0.1.csr.pem

cp server.csr ../ca/crl/127.0.0.1.csr.pem

Em seguida, a função é alterada para a função de CA para processar a solicitação.

Primeiro modifique /root/ca/openssl.cnf

policy            = policy_strict
改为
policy            = policy_loose

policy_strict é usado apenas ao gerar um certificado raiz. Outras vezes, basta usar a política flexível.

# cd /root/ca
# openssl ca -config openssl.cnf \
  -extensions server_cert -days 375 -notext -md sha256 \
  -in crl/127.0.0.1.csr.pem \
  -out certs/127.0.0.1.cert.pem

-dias 375: O período de validade é 375 dias, o valor padrão também é 375 dias

Neste momento você encontrará

Há um 127.0.0.1.cert.pem adicional em /root/ca/certs (este é o certificado gerado) Há um 1000.pem adicional em newcerts (este é o backup do certificado, 1000 é retirado do serial) /root/ca/index.txt tem mais linhas

/root/ca/index.txt
V   171014020124Z       1000    unknown /C=CN/ST=Some-State/O=Internet Widgits Pty Ltd/CN=127.0.0.1

O valor em /root/ca/serial +1 torna-se 1001. Envie o certificado /root/ca/certs/127.0.0.1.cert.pem ao usuário e o trabalho da função CA será concluído.

Depois de mudar a função de volta para o usuário, copiamos o 127.0.0.1.cert.pem enviado pela CA para o diretório /root/127.0.0.1 e o renomeamos para server.crt.

Neste momento, temos os três arquivos a seguir no diretório

server.crt server.csr server.key

server.crt é o certificado que queremos. Podemos configurar o nginx para suportar https.

configuração nginx

server {
    listen       443;
    server_name  127.0.0.1;

    ssl on;
    ssl_certificate      /root/127.0.0.1/server.crt;
    ssl_certificate_key  /root/127.0.0.1/server.key;
    ssl_session_cache    shared:SSL:1m;
    ssl_session_timeout  10m;
    ssl_ciphers  HIGH:!aNULL:!MD5;
    ssl_prefer_server_ciphers  on;

    location / {
        proxy_pass   http://127.0.0.1;
    }

    location ~ ^(.*)\/\.svn\/ {
        deny all;
    }
}

Para oferecer suporte ao Tomcat, também precisamos realizar as seguintes operações.

# cd /root/127.0.0.1
# openssl pkcs12 -export \
    -in server.crt \
    -inkey server.key \
    -out server.p12

输入两次密码:server123456

# keytool -importkeystore -v \
    -srckeystore  server.p12 \
    -srcstoretype pkcs12 \
    -srcstorepass server123456 \
    -destkeystore server.keystore \
    -deststoretype jks \
    -deststorepass server123456

Diretório de arquivos após a operação

server.crt      server.csr      server.key  
server.p12      server.keystore 

configuração do tomcat

<Connector SSLEnabled="true" clientAuth="false" 
keystoreFile="/root/127.0.0.1/server.keystore" 
keystorePass="server123456" 
maxThreads="150" port="8443" protocol="org.apache.coyote.http11.Http11Protocol" scheme="https" secure="true" sslProtocol="TLS"/>

terminando Se precisarmos gerar outros certificados de servidor no futuro, podemos simplesmente começar com 3. Gerando certificados de servidor. Não é muito fácil?

Referência:

https://jamielinux.com/docs/openssl-certificate-authority/index.html http://blog.csdn.net/RazerTang/article/details/46898051/ computador sistema https ca

Compartilhar:

1 Você não deve procrastinar ao fazer as coisas. Originalmente, planejei terminar duas artes esta semana, mas estava ocupado com outras coisas e só consegui escrever uma. 2 Eu realmente admiro Cui Yongyuan. Ele primeiro relatou isso ao fbb e, como mostrado abaixo, Cui fez algo que muitas pessoas queriam não fazer, ou coisas que ousaram fazer, mas não conseguiram. A consequência foi que Cui foi ameaçado de morte. A China carece de pessoas como Cui. Que Cui esteja seguro.