Certificate Revocation List, 403, self signed CRL

 https://www.techtarget.com/searchsecurity/definition/Certificate-Revocation-List#:~:text=A%20certificate%20revocation%20list%20(CRL)%20is%20a%20list%20of%20digital,actual%20or%20assigned%20expiration%20date.

• A user (client) submits their digital certificate through the access point.
• The access point sends the certificate to the authentication server for authentication.
• The server checks to see if the certificate is expired.
• If the certificate is valid (i.e., not expired), the server checks the directory containing the details of approved users.
• If the user is found in the directory, the server next checks the CRL to confirm if the certificate is revoked (identified by the certificate serial number).
• If the certificate is not revoked, i.e., the serial number is not in the CRL, the user is allowed to access the network.

If CA has CRL, it is contained in cert:

CRL Distribution Point

     Distribution Point Name:

          Full Name:

               URL=xxxxxxxxxxmyca.crl.com/checkme

if this end point is not accessible, 403 will be returned :

https://serverfault.com/questions/450676/how-often-is-crl-refreshed-and-how-to-force-it-to-be

If the CRL cannot be reached, IIS returns a 403.13 by default.

Python, django offer to host crl for ur own self signed ca:

https://django-ca.readthedocs.io/en/latest/crl.html

Certificate bag attributes in PEM

 https://stackoverflow.com/questions/72866563/what-are-bag-attributes-in-pemfiles-and-do-they-matter-in-the-file-i-mean-can

ag attributes are generated by OpenSSL during PFX conversion to PKCS#1/PKCS#8 PEM private key files. These attributes are not signed and are completely optional. See this thread for more information: What are bag attributes and how can i generate them?

Certificate - CSR, CA Signing , how it works -2026 use same ca to renew certificate

 https://www.globalsign.com/en-sg/blog/what-is-a-certificate-signing-request-csr

https://en.wikipedia.org/wiki/Certificate_signing_request

What is certificate sign request(CSR)

Procedure

[edit]

Before creating a CSR for an X.509 certificate, the applicant first generates a key pair, keeping the private key of that pair secret, e.g.:

# https://www.openssl.org/docs/manmaster/man1/openssl-genrsa.html
# "openssl genrsa" creates an RSA private key:

$ openssl genrsa -out 2024_wikipedia.org.key

The CSR contains information identifying the applicant (such as a distinguished name), the public key chosen by the applicant, and possibly further information. When using the PKCS #10 format, the request must be self-signed using the applicant's private key, which provides proof-of-possession of the private key but limits the use of this format to keys that can be used for (some form of) signing. The CSR should be accompanied by a proof of origin (i.e., proof of identity of the applicant) that is required by the certificate authority, and the certificate authority may contact the applicant for further information.

Typical information required in a CSR (sample column from sample X.509 certificate). Note that there are often alternatives for the Distinguished Names (DN), the preferred value is listed.

DN[2]	Information	Description	Sample
CN	Common Name	This is fully qualified domain name that you wish to secure	*.wikipedia.org
O	Organization Name	Usually the legal name of a company or entity and should include any suffixes such as Ltd., Inc., or Corp.	Wikimedia Foundation, Inc.
OU	Organizational Unit	Internal organization department/division name	IT
L	Locality	Town, city, village, etc. name	San Francisco
ST	State	Province, region, county or state. This should not be abbreviated (e.g. West Sussex, Normandy, New Jersey).	California
C	Country	The two-letter ISO code for the country where your organization is located	US
EMAIL	Email Address	The organization contact, usually of the certificate administrator or IT department

This sample command line uses the details as listed in the table above:

# https://www.openssl.org/docs/manmaster/man1/openssl-req.html
# "openssl req" creates a signing request:

$ openssl req -sha512 -new -subj "/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikipedia.org" -key 2024_wikipedia.org.key -out 2024_wikipedia.org.csr

This CSR(cert) need to signed by CA's private key , so installed browser has CA' public key to verify CA, then browser send receive server certificate, create a session key using server public key:

https://www.blogger.com/blog/post/edit/2746942211977437381/9146858904040583558

The client sends session key information, encrypted with the server's public key.

The server decrypts the data sent using its private key. The data is used to create a symmetric key.

The client sends its digital certificate, which includes its public key.

The client sends "Certificate Verify" message, which is signed using its private key.

The server verifies the client's certificate and "Certificate Verify" message using the client's public key.

The client and the server exchange "Finished" messages, encrypted with the symmetric key.

CA sign CSR

https://www.ibm.com/docs/en/license-metric-tool?topic=certificate-step-2-signing-certificates

openssl x509 -signkey path_to_CA_key.key -days 

number_of_days -req -in path_to_CA_csr.csr 

-out CA_certificate_name.arm -sha256

---------------------------

renewal

Most common/simple renewal:

existing files:
server.key
server.crt
ca.crt
ca.key
server.ext

Option 1: Renew using the same private key

This keeps the same server.key.

1. Create a new CSR from the existing private key

openssl req -new -key server.key -out server-renew.csr

Use the same Common Name as before, for example:

mydomain.com

2. Sign it again with your CA

openssl x509 -req \
  -in server-renew.csr \
  -CA ca.crt \
  -CAkey ca.key \
  -CAcreateserial \
  -out server-renew.crt \
  -days 365 \
  -sha256 \
  -extfile server.ext

Now replace the old cert:

cp server.crt server.crt.bak
cp server-renew.crt server.crt

Your pair is still:

server.crt
server.key

Then restart/reload your server.

------need a server.ext

server.ext can be just:

authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage=digitalSignature,keyEncipherment
extendedKeyUsage=serverAuth
subjectAltName=@alt_names

[alt_names]
IP.1=160.223.160.145

You only add DNS lines when clients connect using a domain name, for example:

[alt_names]
DNS.1=example.com
DNS.2=www.example.com
IP.1=160.223.160.145

So the rule is:

Client connects to https://160.223.160.145  -> use IP.1
Client connects to https://example.com      -> use DNS.1

make p12:

openssl pkcs12 -export -in jxiangclientdev.crt -inkey jxiangclientdev.key -out jxiangclientdev.key.p12

one way SSL (browser sever) two way SSL authentication + encryption

 https://dzone.com/articles/implementing-one-way-and-two-way-ssl-mutual-authen

One Way SSL

As mentioned above in one way SSL only client verifies the server certificates. At the server end, there will be a Keystore that will hold the private and public certificate of the server whereas, at the client end, there will be a truststore that will hold the public certificate of the server.

• Clients will send Hello and request for the resources on the secure HTTPS protocol.
• The server will respond with its public certificate (.crt) and send Hello.
• The client will verify the server public certificate in its truststore.
• The client sends back symmetric session key generated using the server public certificate.
• The server will decrypt the symmetric session key using its private key and send back the encrypted session key encrypted to the client for establishing a secure connection.

Two Way SSL (Mutual Authentication)

As mentioned above in two ways SSL client verifies the server certificates and the server verifies the client certificates. 

At the server end, there will be a Keystore which will hold the private and public certificate of the server and truststore which will hold the public certificate of client whereas, at the client end, there will be a Keystore which will hold the private and public certificate of client whereas truststore which will hold the public key of the server.

• Clients will send Hello and request for the resources on the secure HTTPS protocol.
• The server will respond with its public certificate (.crt) and send Hello.
• The client will verify the server public certificate in its truststore.
• The client sends back symmetric session key generated using the server public certificate.
• The server will decrypt the symmetric session key using the server private key and request for the client certificate.
• The client will send its public certificate to the server and the server will verify the client public certificate in the server truststore.
• The server will generate a session key and encrypt using the client public certificate and send it to the client.
• The client will decrypt the session key using client private certificate and this way the key exchange between client and server. It will establish secure communication between client and server.

once session key is created, data encrypted with session key and using algorthim

TLS is just upgraded version of SSL

open SSH VS OPENSSL

 https://security.stackexchange.com/questions/3424/how-is-openssl-related-to-openssh

OpenSSH is a program depending on OpenSSL the library, specifically OpenSSH uses the libcrypto part of OpenSSL.

It's worth mentioning that OpenSSH does not use the TLS protocol thats used for HTTPS etc. OpenSSH uses some of the OpenSSL cryptographic primatives.

https://kinsta.com/knowledgebase/ssh-vs-ssl/#:~:text=The%20key%20difference%20between%20SSH,as%20you%20can%20with%20SSH.

The key difference between SSH vs SSL is that SSH is used for creating a secure tunnel to another computer from which you can issue commands, transfer data, etc.

On the other end, SSL is used for securely transferring data between two parties – it does not let you issue commands as you can with SSH.

SSL certificate common name, SAN, subject

subject:

https://stackoverflow.com/questions/650017/what-does-subject-mean-in-certificate#:~:text=The%20subject%20of%20the%20certificate,owner%22%20of%20the%20certificate).

 

The subject field identifies the entity associated with the public key stored in the subject public key field. The subject name MAY be carried in the subject field and/or the subjectAltName extension.

X.509 certificates have a Subject (Distinguished Name) field and can also have multiple names in the Subject Alternative Name extension.

The Subject DN is made of multiple relative distinguished names (RDNs) (themselves made of attribute assertion values) such as "CN=yourname" or "O=yourorganization".

common name is part of subject

common name 

common name usually only matters in the subject, which is the name of the domain that cert is given to.

https://support.dnsimple.com/articles/what-is-common-name/#commonname-format

he Common Name (AKA CN) represents the server name protected by the SSL certificate. The certificate is valid only if the request hostname matches the certificate common name. Most web browsers display a warning message when connecting to an address that does not match the common name in the certificate.

The common name is not a URL. It doesn’t include any protocol (e.g. http:// or https://), port number, or pathname. For instance, https://example.com or example.com/path are incorrect. In both cases, the common name should be example.com.

It must precisely match the server name where the certificate is installed. If the certificate is issued for a subdomain, it should be the full subdomain. For instance, for the www and api subdomains of example.com, the common name will be www.example.com or api.example.com, and not example.com.

SAN 

Subject Alternative Name

a list of common name cert is protecting

he common name can only contain up to one entry: either a wildcard or non-wildcard name. It’s not possible to specify a list of names covered by an SSL certificate in the common name field.

The Subject Alternative Name extension (also called Subject Alternate Name or SAN) was introduced to solve this limitation. The SAN allows issuance of multi-name SSL certificates.

The ability to directly specify the content of a certificate SAN depends on the Certificate Authority and the specific product. Most certificate authorities have historically marketed multi-domain SSL certificates as a separate product. They’re generally charged at a higher rate than a standard single-name certificate.

On the technical side, the SAN extension was introduced to integrate the common name. Since HTTPS was first introduced in 2000 (and defined by the RFC 2818), the use of the commonName field has been considered deprecated, because it’s ambiguous and untyped.

The CA/Browser Forum has since mandated that the SAN would also include any value present in the common name, effectively making the SAN the only required reference for a certificate match with the server name. The notion of the common name survives mostly as a legacy of the past. There are active discussions to remove its use from most browsers and interfaces.

Cat Pem into singline string, make public private key from p12 . Print pem file with in a single line string (useful for saml 2024) - convert cert to string!!! 2025

 https://serverfault.com/questions/466683/can-an-ssl-certificate-be-on-a-single-line-in-a-file-no-line-breaks

//clean up your pem to remove bag attributes

1) print a single line string with \n for line breaks(this is needed because many software will not working properly with

awk 'NF {sub(/\r/, ""); printf "%s\\n",$0;}'  ca.pem

2) print a single line string without \n (SAML metadata etc)

awk 'NF {sub(/\r/, ""); printf "%s",$0;}' ca.pem

make public private key from p12

openssl pkcs12 -in my.p12 -out fullchain.pem -clcerts -nokeys
openssl pkcs12 -in my.p12 -nodes -nocerts -out privkey.pem

HTTP/SSL lets encrypt, or CA either uses private/public key pair from your own server or they generate for u, browser HTTPS validation

 browser https validation:

https://www.linkedin.com/pulse/how-does-your-browser-knows-tls-certificate-presented-ehis-iribhogbe

lets encrypt how it works:

https://letsencrypt.org/how-it-works/

The official Let’s Encrypt client can either use an already-created key pair, which you can generate under any circumstances you prefer, or it can perform the generation for you, which it will do with OpenSSL, see letsencrypt/crypto_util.py 184.

*Note: generation for you meaning that it will run script to generate public/private key pairs on your server.

def make_key(bits):

    """Generate PEM encoded RSA key.

    :param int bits: Number of bits, at least 1024.

    :returns: new RSA key in PEM form with specified number of bits

    :rtype: str

    """

    assert bits >= 1024  # XXX

    key = OpenSSL.crypto.PKey()

    key.generate_key(OpenSSL.crypto.TYPE_RSA, bits)

    return OpenSSL.crypto.dump_privatekey(OpenSSL.crypto.FILETYPE_PEM, key)