Issue with generating self-sign certificate with proper SAN field

opensslself-signed-certificatessl-certificate

I am trying to configure Janus Gateway and I am experiencing with an issue with my self-signed certificate, see log below

Jan 25 09:50:46 localhost platform: [2018/01/25 09:50:46 EST] [EROR] /api/v4/webrtc/token:WebRTC.Token code=500 rid=7mgqedeejpnt3gginnpj5ikape uid=k7m4t6r663frfqaoo5enspfuqh ip=192.168.20.3 We encountered an error while connecting to the server [details: Post https://192.168.20.140:7889/admin: x509: cannot validate certificate for 192.168.20.140 because it doesn't contain any IP SANs]

My hostname is webrtc, IP address is 192.168.20.140 and local DNS is 192.168.20.1

My understanding is I probably didnd't have the SAN information in my certificate so I modified the command that generates the certificate request by following online tutorials. See my configuration file below.

[ req ]
default_bits            = 2048                  # RSA key size
encrypt_key             = yes                   # Protect private key
default_md              = sha256                # MD to use
utf8                    = yes                   # Input is UTF-8
string_mask             = utf8only              # Emit UTF-8 strings
prompt                  = yes                   # Prompt for DN
distinguished_name      = san_dn           # DN template
x509_extensions     = v3_ca
req_extensions          = san_reqext       # Desired extensions
x509_extensions     = usr_cert

[ san_dn ]
countryName             = "1. Country Name (2 letters) (eg, US)       "
countryName_max         = 2
stateOrProvinceName     = "2. State or Province Name   (eg, region)   "
localityName            = "3. Locality Name            (eg, city)     "
organizationName        = "4. Organization Name        (eg, company)  "
organizationalUnitName  = "5. Organizational Unit Name (eg, section)  "
commonName              = "6. Common Name              (eg, full name)"
commonName_max          = 64

[ san_reqext ]
subjectKeyIdentifier    = hash
basicConstraints    = CA:FALSE
keyUsage                = critical,digitalSignature
extendedKeyUsage        = critical,codeSigning, msCodeInd, msCodeCom
nsCertType      = client,server,email,objsign
subjectAltName      = @alt_names

[ usr_cert ]
subjectKeyIdentifier    = hash
basicConstraints    = CA:FALSE
keyUsage                = critical,digitalSignature
extendedKeyUsage        = critical,codeSigning, msCodeInd, msCodeCom
nsCertType      = client,server,email,objsign
authorityKeyIdentifier  = keyid,issuer

[ alt_names ]
DNS.0           = localhost
DNS.1           = webrtc
DNS.2           = 192.168.20.140
DNS.3           = 192.168.20.1

Below is the command I use to generate my certificate request

openssl req -new -key ./webrtc_secret.key -config ./san_request.cfg -out ./webrtc.csr

Below is the command I use to generate the certificate using my self-sign CA and generated certificate request

openssl x509 -req -in ./webrtc.csr -CA ./rootCA.pem -CAkey ./rootCA.key -CAcreateserial \
-out ./webrtc.pem -days 365 -sha256

Can you spot anything wrong with my certificate request?

Update 1:

Looks like my generated certificate request has the right information.

Requested Extensions:
    X509v3 Subject Key Identifier: 
        F0:CA:B8:FE:FA:CE:29:CE:0E:CB:01:93:B6:97:96:30:8E:B3:16:DB
    X509v3 Basic Constraints: 
        CA:FALSE
    X509v3 Key Usage: critical
        Digital Signature
    X509v3 Extended Key Usage: critical
        Code Signing, Microsoft Individual Code Signing, Microsoft Commercial Code Signing
    Netscape Cert Type: 
        SSL Client, SSL Server, S/MIME, Object Signing
    X509v3 Subject Alternative Name: 
        DNS:localhost, DNS:webrtc, DNS:192.168.20.140, DNS:192.168.20.1

Update 2
So you would think openssl would use all your information from the certificate request when generating the certificate. WRONG! I have to manually specify the extension when generating the self-sign certificate using certificate request. See below example below… This might be the answer. I am going to try it now

openssl x509 -req -in ./webrtc.csr -CA ./rootCA.pem -CAkey ./rootCA.key -CAcreateserial -out ./webrtc.pem -days 365 -sha256 -extfile ./san_ext.cfg -extensions san_reqext

[ req ]
req_extensions          = san_reqext       # Desired extensions

[ san_reqext ]
subjectAltName      = @alt_names

[ alt_names ]
DNS.0           = localhost
DNS.1           = mattermost
IP.0            = 192.168.20.140
IP.1            = 192.168.20.1

Not sure where is the lost of information.

Best Answer

The IP addresses in the Subject Alternate Name section need to be identified as IP, instead of DNS. So change the alt_names section of your OpenSSL configuration file to look like this:

[ alt_names ]
DNS.0           = localhost
DNS.1           = webrtc
IP.0            = 192.168.20.140
IP.1            = 192.168.20.1

Then regenerate the request and certificate.

Related Solutions

How to Verify IIS7 SSL Renewal CSR with OpenSSL

The structure of this IIS7 renewal request is actually quite elegant. It seems to start from the premise that because this is a request to renew a current certificate, it needs to prove that the request is coming from the correct host -- i.e. the host that is actually using the current certificate & ∴ owns the associated private key. In the Internet world, you prove that you are allowed to request renewals for a certificate by authenticating to your CA as the original user, rather than creating a signed CSR.

To prove the right to issue a renewal request, IIS7 creates a normal CSR (PKCS#10 object), and then signs it, and provides the cert of the key that signed it.

IIS7 renewal CSR
- PKCS#7 Data
  - PKCS#10 Data (the ordinary CSR)
- Normal server certificate
- Issuing CA data
- RSA signature (I assume)

Use openssl asn1parse -in iis7rcsr -i to see the structure of the file, and compare this to normal CSRs. You should see an OCTET STRING near the beginning, in an object labelled ":pkcs7-data", which is what you need to extract to get the CSR.

$ openssl asn1parse -in iis7rcsr -i
0:d=0  hl=4 l=4273 cons: SEQUENCE          
4:d=1  hl=2 l=   9 prim:  OBJECT            :pkcs7-signedData
15:d=1  hl=4 l=4258 cons:  cont [ 0 ]        
19:d=2  hl=4 l=4254 cons:   SEQUENCE          
23:d=3  hl=2 l=   1 prim:    INTEGER           :01
26:d=3  hl=2 l=  11 cons:    SET               
28:d=4  hl=2 l=   9 cons:     SEQUENCE          
30:d=5  hl=2 l=   5 prim:      OBJECT            :sha1
37:d=5  hl=2 l=   0 prim:      NULL              
39:d=3  hl=4 l=2426 cons:    SEQUENCE          
43:d=4  hl=2 l=   9 prim:     OBJECT            :pkcs7-data
54:d=4  hl=4 l=2411 cons:     cont [ 0 ]        
58:d=5  hl=4 l=2407 prim:      OCTET STRING      [HEX DUMP]:3082096330820...

In order to get the actual PKCS#10 CSR out of here, we need that offset number, "58" in this example. Then we can use that offset to extract the binary version of that object :-

$ openssl asn1parse -in iis7rcsr -strparse 58 -out thecsr -noout

Next we can read that output file 'thecsr' with openssl req, remembering to specify the input format DER.

$ openssl req -in thecsr -inform DER -text -noout
Certificate Request:
Data:
    Version: 0 (0x0)
    Subject: (normal CSR Subject: line, censored)
    Subject Public Key Info:
        Public Key Algorithm: rsaEncryption
...

I can wrap all this up into one command-line with no temporary files (but sadly 2 reads of the original cert), as long as I can use Linux's /proc/self/fd/ to fool openssl (it will do native tricks with file descriptors for password handling, but not normal output).

$ openssl asn1parse -in iis7rcsr -strparse $(openssl asn1parse -in iis7rcsr | grep -A2 ':pkcs7-data'|tail -1|cut -d: -f1) -out /dev/stdout -noout | openssl req -inform DER -noout -text

Certificate Request:
Data:
    Version: 0 (0x0)
    Subject: (Subject: line censored again)
    Subject Public Key Info:
        Public Key Algorithm: rsaEncryption
        RSA Public Key: (1024 bit)
            Modulus (1024 bit):
...

This long command line is directly equivalent to the simple openssl req -in non-iis7rcsr -noout -text that I normally use :-)

Self Signed Root Certificate with SAN in child

It's best to have three different openssl.cnf files on your system. You cannot use a single file for all the operations. And yes, the syntax is a nightmare.

The default one should be restored and kept intact, so the default behavior is not broken in future.
Copy it to your own openssl-test-ca.cnf and modify it accordingly to your needs.
Copy it to your own openssl-san.cnf and modify it accordingly to your needs.

Now, for every operation which involves your own root (or req for it) use:

openssl command -config /.../openssl-test-ca.cnf  more options

For every operation which involves your SAN client cert (or req for it) use the openssl-san.cnf. And correct the subjectAltName = @alternative_names to appear in [v3_req] and [usr_cert] in the openssl-san.cnf file.

Best Answer

Related Solutions

How to Verify IIS7 SSL Renewal CSR with OpenSSL

Self Signed Root Certificate with SAN in child

Related Topic