ARTES #010

ARTES es una actividad iniciada por 由左耳朵耗子--陈皓: Haga al menos una pregunta sobre el algoritmo leetcode cada semana, lea y comente al menos un artículo técnico en inglés, aprenda al menos una habilidad técnica y comparta un artículo con opiniones y pensamientos. (Es decir, Algoritmo, Revisión, Sugerencia y Compartir se denominan ARTS) y persisten durante al menos un año.

##ARTES 010

este es el articulo 10

Pregunta sobre el algoritmo del algoritmo

Hice dos preguntas sobre algoritmos esta semana.

Pregunta 1

Pregunta 767 del algoritmo leetcode. Reorganizar cadena: Dificultad: 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].

Mi idea de resolver el problema, lo primero que pensé fue que si el número de una determinada letra excede la mitad de la longitud de S, entonces se debe devolver “”. La pregunta solo requiere letras minúsculas, así que primero pensé en calcular el número de cada carácter en la cadena S, y luego pensé en ordenar por el número de caracteres. Finalmente, tuve que considerar algunas condiciones límite, la complejidad del tiempo y la complejidad del espacio. La implementación específica es la siguiente. El tiempo de ejecución de LeetCode es 0 ms y la complejidad del tiempo es 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;
}

Pregunta 2

Pregunta 541 del algoritmo leetcode. Cadena inversa II: Dificultad: 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 pregunta es relativamente simple, solo considere algunas situaciones más.

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;
}

Revisión

Este artículo proviene de: https://medium.freecodecamp.org/how-to-become-a-git-expert-e7c38bf54826

Cómo convertirse en un experto en Git Cómo convertirse en un experto en Git

“Fotografía a intervalos de un hombre parado junto a una carretera y un puente durante el día” de Ahsan Avi en Unsplash Fotografía a intervalos de personas paradas al borde de la carretera y en el puente durante el día por Ahsan Avi en Unsplash

Cometí un error en mi confirmación, ¿cómo lo soluciono? Cometí un error al enviar el código, ¿cómo debo corregirlo?

Mi historial de confirmaciones es un desastre, ¿cómo puedo hacerlo más ordenado? Mi historial de confirmación de código es un desastre, ¿cómo lo mantengo ordenado?

Si alguna vez ha tenido las preguntas anteriores, esta publicación es para usted. Esta publicación cubre una lista de temas que lo convertirán en un experto en Git. Si alguna vez ha tenido las preguntas anteriores, este artículo es para usted. Este artículo cubre una variedad de temas que lo convertirán en un experto en Git.

Si no conoce los conceptos básicos de Git, haga clic aquí para consultar mi blog sobre los conceptos básicos de Git. Es necesario que conozcas los conceptos básicos de Git para aprovechar al máximo este artículo. Si no conoce los conceptos básicos de Git, haga clic aquí para ver mi blog sobre conceptos básicos de Git. Es necesario comprender los conceptos básicos de Git para aprovechar al máximo este artículo.

“Placa de cerámica rota en el suelo” de chuttersnap en Unsplash Plato de cerámica roto en el suelo por chuttersnap en Unsplash

Escenario 1 Escenario 1

Digamos (suponiendo) que ha confirmado un montón de archivos y se ha dado cuenta de que el mensaje de confirmación que ingresó en realidad no está claro. Ahora desea cambiar el mensaje de confirmación. Para hacer esto puedes usar git commit --amend

Digamos que confirmas un montón de archivos y te das cuenta de que el mensaje de confirmación que ingresaste no está realmente claro. Ahora es necesario cambiar el mensaje de confirmación. Para hacer esto puedes usar git commit -amend

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

Escenario 2 Escenario 2

Digamos que desea confirmar seis archivos pero, por error, termina confirmando solo cinco archivos. Puede pensar que puede crear una nueva confirmación y agregar el sexto archivo a esa confirmación.

Digamos que desea enviar 6 archivos, pero por error termina enviando solo 5 archivos. Podría pensar que podría crear una nueva confirmación y agregar un sexto archivo a esa confirmación.

No hay nada de malo en este enfoque. Pero, para mantener un historial de confirmaciones ordenado, ¿no sería mejor si de alguna manera pudieras agregar este archivo a tu confirmación anterior? Esto también se puede hacer a través de git commit --amend:

No hay nada de malo en este enfoque. Sin embargo, para mantener un historial de confirmaciones ordenado, ¿no sería mejor si de alguna manera pudiera agregar este archivo a la confirmación anterior? Esto se puede lograr con ‘git commit -amend’:

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

--no-edit significa que el mensaje de confirmación no cambia.

Escenario 3 Escena 3

Siempre que realiza una confirmación en Git, la confirmación tiene un nombre de autor y un correo electrónico del autor vinculados. Generalmente, cuando configuras Git por primera vez, configuras el nombre del autor y el correo electrónico. No necesita preocuparse por los detalles del autor de cada confirmación.

Siempre que realiza una confirmación en Git, la confirmación tiene un nombre de autor y un correo electrónico del autor. Normalmente, cuando configura Git por primera vez, configura su nombre de autor y correo electrónico. No necesita preocuparse por los detalles del autor de cada envío.

Dicho esto, es posible que para un proyecto en particular desees utilizar una ID de correo electrónico diferente. Debes configurar la identificación de correo electrónico para ese proyecto con el comando: Dicho esto, es posible que desees utilizar una ID de correo electrónico diferente para un proyecto específico. Debe configurar el ID de correo electrónico del proyecto usando el siguiente comando:

git config user.email “your email id”

Digamos que olvidó configurar el correo electrónico y ya realizó su primera confirmación. Amend también se puede utilizar para cambiar el autor de su confirmación anterior. El autor de la confirmación se puede cambiar usando el siguiente comando:

Digamos que olvidó configurar su correo electrónico y ya realizó su primera confirmación. “Enmendar” también se puede utilizar para cambiar el autor de su envío anterior. El autor de una confirmación se puede cambiar usando:

git commit --amend --author "Author Name <Author Email>"

Señalar nota

Utilice el comando amend solo en su repositorio local. Usar amend para el repositorio remoto puede crear mucha confusión. Utilice únicamente el comando “modificar” en repositorios locales. Usar amend con repositorios remotos puede causar mucha confusión.

Mi historial de compromisos es un desastre. ¿Cómo lo manejo? Mi historial de confirmaciones es un desastre. ¿Cómo lo soluciono?

Digamos que estás trabajando en un fragmento de código. Sabes que el código tardará aproximadamente diez días en completarse. Dentro de esos diez días, los otros desarrolladores también enviarán código al repositorio remoto. Digamos que estás trabajando en un fragmento de código. Verá, el código tarda unos 10 días en completarse. Durante estos diez días, otros desarrolladores también enviarán código al repositorio remoto.

Es una buena práctica mantener actualizado el código de su repositorio local con el código del repositorio remoto. Esto evita muchos conflictos de fusión más adelante cuando genera una solicitud de extracción. Entonces decide que extraerá los cambios del repositorio remoto una vez cada dos días.Es una buena práctica mantener el código del repositorio local actualizado con el código del repositorio remoto. Esto evita muchos conflictos de fusión al realizar solicitudes de extracción en el futuro. Entonces decide extraer cambios del repositorio remoto cada dos días.

Cada vez que extrae el código del repositorio remoto al repositorio local, se crea una nueva confirmación de fusión en su repositorio local. Esto significa que su historial de confirmaciones local tendrá muchas confirmaciones de fusión, lo que puede hacer que las cosas parezcan confusas para el revisor. Cada vez que se extrae código del repositorio remoto al repositorio local, se crea una nueva confirmación de fusión en el repositorio local. Esto significa que su historial de confirmaciones local tendrá muchas confirmaciones de fusión, lo que confundirá a los revisores.

Así es como se vería el historial de confirmaciones en su repositorio local. Así es como se ve el historial de confirmaciones en su repositorio local.

¿Cómo se puede hacer que el historial de confirmaciones se vea más ordenado? Aquí es donde rebase viene al rescate. ¿Cómo puedo hacer que mi historial de confirmaciones luzca más limpio? Aquí es donde rebase viene al rescate.

¿Qué es el rebase? Déjame explicarte esto mediante un ejemplo.

Este diagrama muestra las confirmaciones en la rama de lanzamiento y su rama de características.

1. La rama Release tiene tres confirmaciones: Rcommit1, Rcommit2 y Rcommit3.
2. Creaste tu rama de Funciones desde la rama de Lanzamiento cuando solo tenía una confirmación, que es Rcommit1.
3. Ha agregado dos confirmaciones a la rama Función. Son Fcommit1 y Fcommit2.
4. Su objetivo es llevar las confirmaciones de la rama Release a su rama Feature.
5. Vas a utilizar rebase para hacer esto.
6. Deje que el nombre de la rama de lanzamiento sea lanzamiento y el nombre de la rama de características sea característica.
7. El cambio de base se puede realizar usando los siguientes comandos:

Este diagrama muestra confirmaciones en ramas de lanzamiento y ramas de características.

1. La rama Release tiene tres confirmaciones: Rcommit1, Rcommit2 y Rcommit3.
2. Cuando la rama de lanzamiento tiene solo una confirmación (es decir, Rcommit1), crea la rama de características a partir de la rama de lanzamiento.
3. Ha agregado dos confirmaciones a la rama Función. Son Fcommit1 y Fcommit2.
4. Su objetivo es fusionar las confirmaciones de la rama Lanzamiento en su rama Característica.
5. Necesitas usar rebase para hacer esto.
6. Deje que el nombre de la rama de lanzamiento sea lanzamiento y el nombre de la rama de características sea característica.
7. Puede utilizar el siguiente comando para cambiar la base:

git checkout feature
git rebase release

Rebase

Al realizar el cambio de base, su objetivo es garantizar que la rama de funciones obtenga el código más reciente de la rama de lanzamiento.

Rebasing intenta agregar cada confirmación, una por una, y verifica si hay conflictos. ¿Suena confuso?

Déjame explicarte con la ayuda de un diagrama.

Esto muestra lo que realmente hace el rebase internamente:

Rebase Al cambiar la base, su objetivo es asegurarse de que la rama Característica obtenga el código más reciente de la rama Lanzamiento.

rebase intenta agregar cada confirmación una por una y verifica si hay conflictos. ¿Suena confuso?

Déjame explicarlo con un diagrama.

Esto muestra lo que realmente hace rebase internamente:

Paso 1

1. En el momento en que ejecuta el comando, la rama Característica apunta al encabezado de la rama Lanzamiento.
2. Ahora la rama Característica tiene tres confirmaciones: Rcommit1, Rcommit2 y Rcommit3.
3. Quizás se pregunte qué pasó con Fcommit1 y Fcommit2.
4. Las confirmaciones todavía están ahí y se utilizarán en los pasos siguientes. Paso 2
5. Ahora Git intenta agregar Fcommit1 a la rama Característica.
6. Si no hay conflicto, se agrega Fcommit1 después de Rcommit3
7. Si hay un conflicto, Git te lo notificará y tendrás que resolver el conflicto manualmente. Paso 3
8. Una vez que se agrega Fcommit1, Git intentará agregar Fcommit2.
9. Nuevamente, si no hay conflicto, se agrega Fcommit2 después de Fcommit1 y la rebase se realiza correctamente.
10. Si hay un conflicto, Git te lo notificará y tendrás que resolverlo manualmente.
11. Una vez realizado todo el cambio de base, notará que la rama Característica tiene Rcommit1, Rcommit2, Rcommit3, Fcommit1 y Fcommit2.

Paso 1

1. Al ejecutar el comando, la rama de características apunta al encabezado de la rama de lanzamiento.
2. La rama de funciones ahora tiene tres confirmaciones: Rcommit1, Rcommit2 y Rcommit3.
3. Quizás se pregunte qué pasó con Fcommit1 y Fcommit2.
4. La confirmación todavía existe y se utilizará en los próximos pasos. Paso 2
5. Ahora Git intenta agregar Fcommit1 a la rama de funciones.
6. Si no hay conflicto, agregue Fcommit1 después de Rcommit3
7. Si hay un conflicto, Git te lo notificará y deberás resolver el conflicto manualmente. Paso 3
8. Después de agregar Fcommit1, Git intentará agregar Fcommit2.
9. De manera similar, si no hay conflicto después de Fcommit1, agregue Fcommit2 después de Fcommit1 y la rebase se realizará correctamente.
10. Si ocurre un conflicto, Git te lo notificará y deberás resolverlo manualmente.
11. mostrado. Después de completar todo el cambio de base, notará que las ramas de funciones son Rcommit1, Rcommit2, Rcommit3, Fcommit1 y Fcommit2.

Puntos a tener en cuenta

1. Tanto Rebase como Merge son útiles en Git. Uno no es mejor que el otro.
2. En el caso de una fusión, tendrá una confirmación de fusión. En el caso de una rebase, no hay una confirmación adicional como una confirmación de fusión.
3. Una buena práctica es utilizar los comandos en diferentes puntos. Utilice rebase cuando actualice su repositorio de código local con el código más reciente del repositorio remoto. Utilice la combinación cuando trabaje con solicitudes de extracción para fusionar la rama Característica con la rama Versión o Maestro.

Nota

1. En Git, tanto Rebase como Merge son útiles. Uno no es mejor que el otro.
2. En caso de fusión, tendrá una confirmación de fusión. En caso de rebase, no hay confirmaciones adicionales como las confirmaciones de fusión.
3. La mejor práctica es utilizar diferentes comandos en diferentes lugares. Utilice rebase cuando actualice su repositorio de código local con el código más reciente del repositorio remoto. Al procesar una solicitud de extracción, use merge para fusionar la rama de características nuevamente con la rama de lanzamiento o la rama maestra.

Felicidades

Ahora eres un experto en Git 😃En este post has aprendido sobre:

• modificar compromisos
• rebase Ambos son conceptos muy útiles. Explora el mundo de Git para aprender aún más.

Felicitaciones

Ahora eres un experto en Git

En este artículo aprendiste:

*Modificar y enviar *Rebase Ambos conceptos son útiles. Explora el mundo de Git y aprende más.

Sobre el autor Me encanta la tecnología y sigo los avances en el campo. También me gusta ayudar a otros con mis conocimientos de tecnología.

No dudes en conectarte conmigo en mi cuenta de LinkedIn https://www.linkedin.com/in/aditya1811/

También puedes seguirme en twitter https://twitter.com/adityasridhar18

Otras publicaciones mías Una introducción a Git

Cómo utilizar Git de manera eficiente

CONSEJOS:

Cómo utilizar itms-services para instalar el servidor de distribución ipa empaquetado con certificados empresariales

El proceso de configuración de un servidor es relativamente sencillo. Puedes utilizar Baidu o Google tú mismo. Yo uso nginx en Mac

El servidor que uso es Mac Nginx. La configuración es muy sencilla y hay muchos tutoriales en Internet. La clave ahora es cómo habilitar https.

Después del sistema IOS7.1, si desea utilizar un certificado empresarial ($299) para instalar ipa en línea a través de itms-services, debe utilizar el protocolo https.

nginx habilita la configuración https: https://www.jianshu.com/p/fe0fadb38600、

Hay un paso de reinicio en el artículo de hace un momento: los servicios de elaboración de cerveza reinician nginx

Se recomienda habilitar el registro de errores en el archivo de configuración de nginx, de modo que si hay errores durante el proceso de inicio, pueda verlos directamente. Algunos errores no se pueden ver en el terminal. Por ejemplo, cuando uso los servicios de preparación, reinicio nginx para reiniciar, indica éxito.

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

Pero en realidad fracasó.

Más tarde vi en el registro de errores: bind() a 0.0.0.0:443 falló (13: Permiso denegado)

Necesidad de utilizar: Los servicios sudo brew reinician nginx para comenzar

Aquí hay un concepto que requiere CA, explicación sobre CA: https://www.cnblogs.com/handsomeBoys/p/6556336.html、https://www.jianshu.com/p/57066821b863 En pocas palabras, activar https requiere un certificado. Este certificado debe aplicarse a un sitio web autorizado de terceros o puede crearlo usted mismo. Por supuesto, los sitios web https que se ejecutan en línea deben procesarse como sitios web autorizados de terceros. Porque los certificados autoconstruidos requieren que los usuarios los instalen manualmente y los navegadores no confían en ellos. https no tendría sentido si alguien pudiera crear un certificado. Pero nuestro propósito actual es usarlo en la LAN de la empresa, por lo que utilizamos un certificado de creación propia. El usuario debe instalar manualmente el certificado de creación propia.

El siguiente artículo sobre la configuración de itms-services también es muy claro: http://www.cnblogs.com/feiyiban588/p/5788310.html https://blog.csdn.net/RazerTang/article/details/46898051/

También puede crear una CA siguiendo estos pasos:

Haz tu propia CA

1. Introducción

Antes, mi blog admitía https y utilizaba un certificado gratuito de un año emitido por StartCom CA. StartCom es una CA confiable. Varios sistemas operativos y navegadores confían en su certificado raíz, por lo que también serán confiables los certificados emitidos por él.

Recientemente creé un programa de carga y descarga de paquetes ipa de iOS, que también requiere el uso de enlaces https. Verifiqué en línea y descubrí que puedo firmar el certificado yo mismo, así que lo puse en práctica. Aquí están los pasos detallados.

Recomiendo especialmente el sitio web a continuación, que habla sobre ello en… muy detalle.

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

Hay algunas funciones en el tutorial que simplemente necesitas entender, pero no necesitamos usarlas, así que eliminé algunos de los pasos para hacerlos más simples y fáciles de usar.

2.CA

Cuando usted mismo actúa como CA, utiliza el comando openssl para generar su propio certificado raíz y permitir que los usuarios lo instalen y confíen en él. Entonces también se podrá confiar en todos los certificados firmados con este certificado raíz.

Entonces, como CA, primero debemos generar nuestro propio certificado raíz ca.cert.pem, y generar el certificado raíz requiere ca.key.pem.

empezar Cree la carpeta /root/ca. Todas las operaciones de CA se realizarán en esta carpeta.

 # 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: carpeta CA

/root/ca/certs: la ubicación donde se almacenan el certificado recién firmado y el certificado raíz.

/root/ca/crl: ubicación de almacenamiento del archivo de solicitud de certificado

/root/ca/newcerts: la ubicación donde se almacena el certificado recién firmado, que es una copia de seguridad de /root/ca/certs

/root/ca/private: ubicación de almacenamiento ca.key.pem, no la pierdas

/root/ca/index.txt: registro de firma del certificado

/root/ca/serial: el número de serie de la siguiente firma del certificado, guardado en index.txt

Copie el siguiente contenido en /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 una explicación detallada, puedes ver el enlace de arriba (realmente recomendado). Aquí seleccionaré los importantes.

dir = /root/ca: esto debe cambiarse a la carpeta CA de arriba

política = política_estricta: utilice la política estricta para firmar el certificado de CA

nombre_país_default = CN

0.organizationName_default = SIYOU325 CA

Estos dos son los nombres del país y de la organización, que se mostrarán en el certificado generado. Simplemente firme un certificado de CA. Sólo establecemos estos dos valores y dejamos los demás vacíos.

[v3_ca]: Esta configuración es necesaria para firmar el certificado de CA

[server_cert]: Esto es necesario para firmar el certificado del servidor a continuación

Generar clave raíz

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

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

# chmod 400 private/ca.key.pem

Generar certificado raíz

# 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

-días 7300: Válido por 20 años

En este punto, se han generado ca.key.pem (clave raíz) y ca.cert.pem (certificado raíz). Los caminos son los siguientes.

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

En este punto, se completa la generación del certificado raíz.

La contraseña de ca.key.pem es siyou325123456, que es muy importante y debe guardarse bien.

ca.cert.pem es el certificado raíz. Debe enviarse al usuario para que pueda instalarlo y confiar en él, de modo que todos los certificados que firmemos con este certificado sean confiables en el futuro.

3. Generar certificado de servidor

El trabajo del rol de CA ha sido completado. Ahora usamos la función de usuario para generar un certificado de servidor que Tomcat y nginx pueden usar.

Supongamos aquí que el nombre de dominio o la dirección IP de nuestro sitio web es 127.0.0.1, luego cree la carpeta 127.0.0.1 en el directorio del mismo nivel que ca y genere el certificado del servidor en este directorio.

# 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 después de este comando representa el número de bits de cifrado. Utilice estrictamente 4096. Por ejemplo, el certificado raíz anterior utiliza esto. Generalmente, 2048 y 1024 son suficientes. Cuanto mayor sea el valor, mayor será el tiempo de espera del enlace https.

En este punto, se generan nuestra clave de servidor (server.key) y la solicitud de certificado (server.csr).

Luego copie server.csr a ca/crl y cámbiele el nombre a 127.0.0.1.csr.pem

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

Luego, el rol se cambia al rol de CA para procesar la solicitud.

Primero modifique /root/ca/openssl.cnf

policy            = policy_strict
改为
policy            = policy_loose

Policy_strict solo se usa al generar un certificado raíz. En otras ocasiones, simplemente utilice la política flexible.

# 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

-días 375: el período de validez es de 375 días, el valor predeterminado también es de 375 días

En este momento encontrarás

Hay un 127.0.0.1.cert.pem adicional en /root/ca/certs (este es el certificado generado) Hay 1000.pem adicional en newcerts (esta es la copia de seguridad del certificado, 1000 se toma del número de serie) /root/ca/index.txt tiene más líneas

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

El valor en /root/ca/serial +1 pasa a ser 1001. Envíe el certificado /root/ca/certs/127.0.0.1.cert.pem al usuario y se completará el trabajo de la función de CA.

Después de volver a cambiar el rol al usuario, copiamos el 127.0.0.1.cert.pem que nos envió la CA al directorio /root/127.0.0.1 y le cambiamos el nombre a server.crt.

En este momento tenemos los siguientes tres archivos en el directorio

server.crt server.csr server.key

server.crt es el certificado que queremos. Podemos configurar nginx para que admita https.

configuración 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 admitir Tomcat, también debemos realizar las siguientes operaciones.

# 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

Directorio de archivos después de la operación

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

configuración de 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"/>

finalizando Si necesitamos generar otros certificados de servidor en el futuro, podemos comenzar desde 3. Generar certificados de servidor. ¿No es muy fácil?

Referencia:

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

Compartir:

1 No debes posponer las cosas al hacer las cosas. Originalmente planeé terminar dos artes esta semana, pero estaba ocupada con otras cosas y solo podía escribir una. 2 Realmente admiro a Cui Yongyuan. Primero lo informó a Facebook y luego, como se muestra a continuación, Cui hizo algo que muchas personas no querían hacer, o cosas que se atrevieron a hacer pero no pudieron hacer. La consecuencia fue que Cui fue amenazado de muerte. China carece de gente como Cui. Que Cui esté a salvo.