Technical Information
How to generate correct CSR when the IP address is in CN or SAN? Please ensure that the IP address is mentioned in the SAN extension as IP Address and DNS Name.
When an internal/external IP Address is part of Common Name (CN) or Subject Alternative Name (SAN) care needs to be taken while generating the CSR.
If not done correctly then the latest browsers like Chrome and Edge give an error – “Your connection to this site is not secure.” Note that deprecated Microsoft Internet Explorer does not give any error in this case.
To avoid this problem please ensure that the IP address is mentioned in the SAN extension as DNS Name and IP Address.
A sample configuration file is shown below for Multi-domain Certificate with 1+3 SAN values, where CN has IP-Address-1 and SAN values are IP-Address-2, SAN-1, and SAN-2.
———
[req]
prompt = no
distinguished_name = dn
req_extensions = ext
[dn]
CN = IP-Address-1
O = Org Name
L = Location/City
ST = State/Province
C = 2 digit code
[ext]
subjectAltName = @alt_names
[alt_names]
IP.1 = IP-Address-1
IP.2 = IP-Address-2
DNS.1 = IP-Address-1
DNS.2 = IP-Address-2
DNS.3 = SAN-1
DNS.4 = SAN-2
———
It is recommended to use CSR while requesting Intranet SSL. When you give certificate details then private key is sent over email. This may pose security risk. But generation of CSR with SAN values is not easy. So, steps are shared for the same.
Good question.
It is always recommended to generate CSR on your web server and share with us. This is because the private key generated during the CSR generation remains on your server, within your premises.
On the other hand, if you give certificate details to us, we generate the CSR. It is called Auto-CSR. During this process, private key is generated on our machine. When we ship the Intranet SSL to you, we send the SSL certificate along with the private key. This method is slightly risky because the private key can be intercepted by someone when it is sent through email.
But generation of CSR for Intranet SSL poses some technical challenges. Reason is that modern browsers expect the CSR to have require SAN values correctly specified.
For example, if the Common Name is “abc.local” then the CN=abc.local and SAN value should be DNS=abc.local. But it is not easy to generate CSR with SAN values on Windows or Linux.
Another issue comes when the certificate is to be issued to an IP address. In this case SAN should have two values. They are DNS=[IP-address] and IP=[IP-Address].
If any of these SAN values are not specified while generating the CSR then browser gives ‘Certificate not Trusted’ error.
Of course, we have shared the steps to generate CSR with SAN values. Link is given below.
https://intranetssl.net/ufaq/how-to-create-the-csr-with-san-in-windows-iis/
https://intranetssl.net/ufaq/how-to-create-csr-with-san-values-using-openssl/
Leave a Reply
Installation FAQ
How to generate correct CSR when the IP address is in CN or SAN? Please ensure that the IP address is mentioned in the SAN extension as IP Address and DNS Name.
When an internal/external IP Address is part of Common Name (CN) or Subject Alternative Name (SAN) care needs to be taken while generating the CSR.
If not done correctly then the latest browsers like Chrome and Edge give an error – “Your connection to this site is not secure.” Note that deprecated Microsoft Internet Explorer does not give any error in this case.
To avoid this problem please ensure that the IP address is mentioned in the SAN extension as DNS Name and IP Address.
A sample configuration file is shown below for Multi-domain Certificate with 1+3 SAN values, where CN has IP-Address-1 and SAN values are IP-Address-2, SAN-1, and SAN-2.
———
[req]
prompt = no
distinguished_name = dn
req_extensions = ext
[dn]
CN = IP-Address-1
O = Org Name
L = Location/City
ST = State/Province
C = 2 digit code
[ext]
subjectAltName = @alt_names
[alt_names]
IP.1 = IP-Address-1
IP.2 = IP-Address-2
DNS.1 = IP-Address-1
DNS.2 = IP-Address-2
DNS.3 = SAN-1
DNS.4 = SAN-2
———
Leave a Reply
It is recommended to use CSR while requesting Intranet SSL. When you give certificate details then private key is sent over email. This may pose security risk. But generation of CSR with SAN values is not easy. So, steps are shared for the same.
Good question.
It is always recommended to generate CSR on your web server and share with us. This is because the private key generated during the CSR generation remains on your server, within your premises.
On the other hand, if you give certificate details to us, we generate the CSR. It is called Auto-CSR. During this process, private key is generated on our machine. When we ship the Intranet SSL to you, we send the SSL certificate along with the private key. This method is slightly risky because the private key can be intercepted by someone when it is sent through email.
But generation of CSR for Intranet SSL poses some technical challenges. Reason is that modern browsers expect the CSR to have require SAN values correctly specified.
For example, if the Common Name is “abc.local” then the CN=abc.local and SAN value should be DNS=abc.local. But it is not easy to generate CSR with SAN values on Windows or Linux.
Another issue comes when the certificate is to be issued to an IP address. In this case SAN should have two values. They are DNS=[IP-address] and IP=[IP-Address].
If any of these SAN values are not specified while generating the CSR then browser gives ‘Certificate not Trusted’ error.
Of course, we have shared the steps to generate CSR with SAN values. Link is given below.
https://intranetssl.net/ufaq/how-to-create-the-csr-with-san-in-windows-iis/
https://intranetssl.net/ufaq/how-to-create-csr-with-san-values-using-openssl/
Leave a Reply