General FAQ
We offer a 30% discount on all standard SecureNT Intranet SSL Certificates to educational institutions and non-profit organizations. We offer discount for taking survey and offering testimonials.
Educational / Non-Profit Customers
We offer a 30% discount on all standard SecureNT Intranet SSL Certificates to educational institutions and non-profit organizations.
If you are eligible let us know your requirement. We will send you online payment link for the same.
Regular Customers
We offer one time discount for participating in our survey about your setup and offering testimonial based on your actual experience.
Survey: https://intranetssl.net/user-feedback-survey/
Testimonial: https://intranetssl.net/request-for-a-testimonial/
For protecting multiple IP addresses, Wildcard SSL is not possible. One has to buy either Single Domain or Multi-Domain.
Say, you wish to secure, say an entire range of IP addresses from 192.168.52.1 to 192.168.51.255.
For this, is it possible to buy Wildcard SSL for 192.168.52.*?
Unfortunately, no. That’s not possible.
For securing this IP address range, either one can buy Single Domain for each IP or Multi-Domain Intranet SSL certificate with required IP address in SAN values.
Leave a Reply
Customer can install SecureNT Intranet SSL on unlimited servers, as per our license terms.
Yes. We give unlimited server license. You can install them on as many servers as you want.
Leave a Reply
SecureNT issues Intranet SSL to any internal name without caring for TLD.
We issue Intranet SSL to all internal names, whether they use any regular TLD or not.
Some Private Certifying Authorities do not issue Intranet SSL if your internal domain name uses a regularly used Top Level Domain (TLD) name, including ccTLD reserved for countries.
For example, if your internal domain name is name1.com or name2.net, or name3.us then they won’t issue Intranet SSL Certificate to you. They will insist that you buy their regular SSL Certificate issued by a public CA.
Leave a Reply
We accept payment through bank wire transfer, and PayPal.
We accept payment in multiple ways:
- Wire Transfer (Swift) to our bank account in India
- PayPal (links given under ‘Buy’, ‘Place Order’)
When the order is confirmed we share our Bank details. Upon receipt of payment and certificate details, we ship the certificate usually on the next business day.
Leave a Reply
We accept payment in USD. You can make online payment through credit/debit card via PayPal. We accept wire-transfer from Bank (Swift).
You can place order (buy) the SecureNT Intranet SSL Certificate from this link.
We accept payment in USD. If you wish to pay in local currency, we can help you to by putting you in touch with a reseller. Let us know.
You can pay us online through credit / debit cards using PayPal’s payment service.
You can pay us through Bank Transfer (Wire-Transfer / Swift). We will send our bank details when you place your order.
Leave a Reply
Since the Intranet SSL Certificate is issued to an IP Address or Internal Name located on the internal network of an organization there is no need to validate the CN or O or SAN. DV and OV Validation is required for SSL certificates issued by the public Certifying Authority (CA).
Since the SecureNT Intranet SSL Certificate is issued to an IP Address or Internal Name (localhost, URL, or Server name) located on the internal network of an organization there is no need to validate the Common Name (CN) or Organization name (O) or Subject Alternative Name (SAN) values.
We verify the correctness of the organization’s name from the organization’s public website.
Domain Validation (DV), Organization Validation (OV), and Extended Validation (EV) are required to be done as per the directive of the CA/Browser Forum for SSL certificates issued by the public Certifying Authority (CA).
SecureNT is a private CA.
Leave a Reply
Internal names include hosts and domains that cannot be registered or resolved in public DNS e.g., server01 or server.local, localhost, etc.
Internal names include hosts and domains that cannot be registered or resolved in public DNS e.g., server01 or server.local, localhost, etc.
Internal IP addresses cannot be registered for use on public networks. They include IPv4 or IPv6 addresses the Internet Assigned Numbers Authority (IANA) marks as reserved. The most common reserved ranges are 10.0.0.0-10.255.255.255, 172.16.0.0-172.31.255.255, and 192.168.0.0- 192.168.255.255. More information is available here.
Leave a Reply
We offer Single Domain, Wildcard and Multi-Domain Intranet SSL Certificates.
We have 3 types of Certificates.
- Single Domain: SecureNT Intranet SSL Certificate – Single Domain secures an Intranet Server’s Local Host Name, Server Name, internal/public IP Address, or Web page URL using Secure HTTPS protocol.
- Multi-Domain or SAN Certificate: SecureNT Intranet SSL Certificate – Multi-Domain (1 + 4 SAN) secures an Intranet Server’s Local Host Name, Server Name, internal/public IP Address, or Web page URL plus 4 SAN values using Secure HTTPS protocol. In case you wish to secure more than 1+4 SAN, then you will have to purchase additional SANs in multiples of 5 SAN values. There is no limit to SAN values.
- Wildcard Certificate: SecureNT Intranet SSL Certificate – Wildcard secures an Intranet Server’s Server Name or Web page URL and all sub-domains using Secure HTTPS protocol.
Leave a Reply
A Multi-Domain (or Subject Alternative Name-SAN) certificate can support multiple domains, server names, and IP Addresses with a single domain.
A Multi-Domain (or Subject Alternative Name-SAN) certificate can support multiple domains, server names, and IP Addresses with a single domain.
They reduce SSL cost and maintenance by using a single certificate for multiple websites using SAN.
These certificates are more flexible than Wildcard certificates since they are not limited to a single domain.
Note: Only non-Wildcard names can be added as SAN.
Certificates are valid for a period ranging from 1 to 10 years. One can install the certificate on unlimited servers. We offer a 7-day Free Multi-Domain Certificate.
Leave a Reply
Single Domain SSL Certificate secures an Intranet Server’s Local Host Name, Server Name, internal/public IP Address, or Web page URL using Secure HTTPS protocol.
SecureNT Intranet SSL Certificate – Single Domain secures an Intranet Server’s Local Host Name, Server Name, internal/public IP Address, or Web page URL using Secure HTTPS protocol.
Certificates are valid for a period ranging from 1 to 10 years. One can install the certificate on unlimited servers. We offer a 90-day Free Single Domain Certificate.
Leave a Reply
A Wildcard certificate is a single certificate with a wildcard character (* – star) in the domain name field.
A Wildcard certificate is a single certificate with a wildcard character (* – star) in the domain name field.
This allows the certificate to secure multiple subdomain names of the same base domain.
For example, a wildcard certificate for *.(domainname).com, could be used for www.(domainname).com, mail.(domainname).com, blog.(domainname).com, etc. Also, a special case of (domainname).com is also secured.
Certificates are valid for a period ranging from 1 to 10 years. One can install the certificate on unlimited servers. We offer a 7-day Free Wildcard Certificate.
Leave a Reply
What is an Intranet SSL Certificate? An Intranet SSL certificate is a Private/non-Public SSL (TLS) Certificate issued by SecureNT.
An Intranet SSL certificate is a Private/non-Public SSL (TLS) Certificate issued by SecureNT.
Technically, it is similar to the SSL certificates issued by Public CAs (like DigiCert, GlobalSign, Entrust, Sectigo, or Let’s Encrypt) but it is used on internal networks or private sites.
Thus, the Intranet SSL certificate is installed on the servers of an internal private network. After installation, whenever a user (client PC) on a local network connects to this server using a browser, all data flowing between the client PC and the server is encrypted and no one can read it, even with snooping tools.
Thus, confidential data and passwords flowing on the internal network remain secure from unauthorized users and even hackers.
Leave a Reply
TLD is the acronym used for top-level domain. It’s the last segment of a domain name after the final dot.
TLD is the acronym used for top-level domain. It’s the last segment of a domain name after the final dot.
A great example of a TDL is: .com
The IANA officially recognizes three types of TLDs:
- gTLD – Generic Top-Level Domains
- ccTLD – Country Code Top-Level Domains
- sTLD – Sponsored Top-Level Domains
Your TLD plays an important role in the Domain Name System (DNS). For more information click here.
Leave a Reply
Retail price of SecurNT Intranet SSL for Single Domain, Wildcard and Multi-Domain Certificates.
You may be surprised to know how competitively priced we are, compared to the competition.
SecureNT Intranet SSL Retail Price List (US Dollar) |
||||
Validity (Years) |
Single Domain |
Wildcard |
Multi-Domain |
Additional |
1 |
110 | 270 | 246 |
170 |
2 |
190 | 470 | 422 |
290 |
3 |
270 | 670 | 598 |
410 |
4 |
350 | 870 | 774 |
530 |
5 |
410 | 1,030 | 906 |
620 |
6 |
470 | 1,190 | 1,038 |
710 |
7 |
530 | 1,350 | 1,170 |
800 |
8 |
570 | 1,470 | 1,258 |
860 |
9 |
610 | 1,590 | 1,346 |
920 |
10 | 650 | 1,710 | 1,434 |
980 |
Currently we sell certificates in USD only.
If you wish to purchase them in your local currency, do let us know and we will share details of the reseller who can service your order.
We strongly believe in customer satisfaction. Our sales, SSL certificate issuance, and support policies are designed to meet customer needs.
Leave a Reply
Why use an Intranet SSL on Internal Network Servers? CA/Browser Forum (CA/B) does not allow Public CAs to issue Public SSL Certificates to Private Internal Networks. So, internal/private Servers have to use SSL Certificates from non-public CAs. SecureNT issues Intranet/non-Public SSL Certificates using non-Public Root Certificates.
CA/Browser Forum (CA/B), the regulatory body that governs the SSL industry, does not allow Public CAs to issue Public SSL Certificates to Private Internal Networks covered under IETF RFC 1918.
So, internal/private Servers have to use SSL Certificates from non-public CAs or Self-Signed Certificates.
Of course, some of these Public CAs do issue Intranet/non-Public SSL Certificates using non-Public Root Certificates. SecureNT Intranet SSL does the same but offers it quickly and at a much more attractive price.
Leave a Reply
Technical Information
Are SecureNT Root Certificates trusted by the browsers? No. SecureNT CA Root certificates needs to be installed once.
Intranet SSL certificate’s root certificate chain is not trusted by default on popular browsers like Chrome, Edge, Internet Explorer, Safari, Firefox, etc. This means that unless certain steps are taken, a client PC will get a “certificate not trusted” error when a user uses a web browser to access a website hosted on a Server with Intranet SSL.
But these steps (installation of SecureNT CA root certificates) need to be taken once only. After those steps are taken, the client PC will always trust the Intranet SSL certificate.
You can find the steps here.
Leave a Reply
For protecting multiple IP addresses, Wildcard SSL is not possible. One has to buy either Single Domain or Multi-Domain.
Say, you wish to secure, say an entire range of IP addresses from 192.168.52.1 to 192.168.51.255.
For this, is it possible to buy Wildcard SSL for 192.168.52.*?
Unfortunately, no. That’s not possible.
For securing this IP address range, either one can buy Single Domain for each IP or Multi-Domain Intranet SSL certificate with required IP address in SAN values.
Leave a Reply
SecureNT Intranet SSL Certificates are issued by default with RSA Encryption, 2048 bit Key Size, and Sha256 Hash Algorithm
- Certificates are issued by default with RSA Encryption, 2048 bit Key Size, and Sha256 Hash Algorithm
- The Root Certificate chain is from Secure Network Traffic
- Custom Root Certificate chain on your organization name is available on request
- Client Authentication Certificates for Single Sign-on and Document Management / Signing available on request.
- RSA Certificates with different Key Size and Hash Algorithm available on request
- ECDSA Certificates with 256 and 384-bit Key Size also available on request
Leave a Reply
SecureNT issues Intranet SSL to any internal name without caring for TLD.
We issue Intranet SSL to all internal names, whether they use any regular TLD or not.
Some Private Certifying Authorities do not issue Intranet SSL if your internal domain name uses a regularly used Top Level Domain (TLD) name, including ccTLD reserved for countries.
For example, if your internal domain name is name1.com or name2.net, or name3.us then they won’t issue Intranet SSL Certificate to you. They will insist that you buy their regular SSL Certificate issued by a public CA.
Leave a Reply
This FAQ shows how to create a Certificate Signing Request (CSR) file with SAN values on the webserver using OpenSSL.
For creating CSR with SAN values (X.509 v3 Extension) it’s important to create a configuration file with the required certificate details. Execute following command in openssl.
openssl req -newkey rsa:2048 -nodes -keyout pvtkey.cer -config config.cnf -out csr.txt -utf8
It will create a Private key (pvtkey.cer) and CSR file (csr.txt).
Sample Configuration file (config.cnf)
[req]
prompt = no
distinguished_name = dn
req_extensions = ext
[dn]
CN = 192.168.2.23
O = Abc Corporation
L = Sydney
ST = New South Walse
C = AU
[ext]
subjectAltName = @alt_names
[alt_names]
IP.1 = 192.168.2.23
IP.2 = 10.12.4.122
DNS.1 = 192.168.2.23
DNS.2 = 10.12.4.22
DNS.3 = sms.abc.local
DNS.4 = localhost
It will generate CSR with CN=192.168.2.23 and 3 SAN values: 10.12.4.122, sms.abc.local and localhost.
Notice that when IP address is there in CN or SAN, we need to put its value against both IP Address and DNS. For others (URL, Servername etc) only DNS value is required.
Leave a Reply
This FAQ explains how to generate CSR on Microsoft Windows Server running IIS (any version) with SAN (Subject Alternative Name) values.
Following steps are applicable for all versions of IIS. Windows Server should be domain joined.
- Open the MMC console and add the Certificate snap-in to it as Local Computer. Right Click Personal node on the left and Select All Tasks –>Advanced Operations –> Create Custom Request.
- Choose Proceed without enrollment policy and Click Next. Choose No Template Legacy Key for compatibility reasons. Use PKCS#10.
- Click Next and click Properties. Give a friendly name for the certificate and a description. Ensure that you hit Apply as soon as you are done with the tab.
- Click on Subject tab and add all the hostnames under “Alternative Name“. Under Subject Name, enter the Common Name (CN), Organization (O), City (L), State (S) and Country (C) code (2 character) values. Click Apply.
- Under the Extensions tab, expand Extended Key Usage (application policies) and select Server Authentication and Client Authentication. Click Apply.
- Under the Private Key tab, set the Key size to 2048 under Key options. Tick Make Private Key exportable. Select Exchange as the Key type. Click Apply. Click OK.
- Select a location to save the file. Choose the file format as Base 64. Click Finish.
CSR is generated with SAN values.
Leave a Reply
Installation of SSL Certificate in Windows Azure environment is different. It requires a special password protected PFX file with Triple DES encryption. Please mention this requirement while placing request to us. We will send this special PFX file.
Installation of SSL Certificate in Windows Azure environment is different. It requires a special password protected PFX file with Triple DES encryption. Please mention this requirement while placing request to us. We will send this special PFX file.
Installation steps are given on this blog.
Leave a Reply
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 says how to install the issued SSL Certificate on Ubuntu Linux. It requires ‘openssl’ package to convert the certificate from PFX to PEM format. Then one needs to copy the PEM file to /etc/ssl/certs directory.
If you asked for the Intranet SSL without CSR, you would have received server.pfx file on email.
1. Copy the server.pfx file to the Ubuntu machine
2. Ensure that openssl package is installed on Ubuntu
3. Run the following command:
sudo openssl pkcs12 -in server.pfx -passin pass:inetssl2 -out serverpfx.pem -nodes
This will create a serverpfx.pem file, which contains the issued certificate, two CA certificates and the private key.
4. Move the serverpfx.pem file to /etc/ssl/certs/
5. Update the permissions:
sudo chmod 644 /etc/ssl/certs/serverpfx.pem
6. Restart the Apache service:
sudo service apache2 restart
In case, you wish us to make the serverpfx.pem file, write back to us on support@intranetssl.net
Leave a Reply
We issue SecureNT Intranet SSL certificate in PEM format with .cer extension. The DER format is the binary form of the certificate.
We issue SecureNT Intranet SSL certificate in PEM format with .cer extension.
The PEM format is the most common format used for certificates. Extensions used for PEM certificates are cer, crt, and pem. They are Base64 encoded ASCII files.
PEM formatted certificates contain the “Begin Certificate/End Certificate” statements.
The DER format is the binary form of the certificate. DER formatted certificates do not contain the “BEGIN CERTIFICATE/END CERTIFICATE” statements.
DER formatted certificates most often use the ‘.der’ extension. Root Certificates on Resource page are in DER format.
In case, you want them in PEM format send Email to support@intranetssl.net
Leave a Reply
It’s not compulsory to provide CSR to get Intranet SSL Certificate. Just fill-up the form and we will generate the CSR. And we will send the SSL Certificate along with the private key.
Not necessary.
Just fill-up the form and we will generate the CSR (called Auto-CSR). And we will send the SSL Certificate along with the private key.
Leave a Reply
Internal names include hosts and domains that cannot be registered or resolved in public DNS e.g., server01 or server.local, localhost, etc.
Internal names include hosts and domains that cannot be registered or resolved in public DNS e.g., server01 or server.local, localhost, etc.
Internal IP addresses cannot be registered for use on public networks. They include IPv4 or IPv6 addresses the Internet Assigned Numbers Authority (IANA) marks as reserved. The most common reserved ranges are 10.0.0.0-10.255.255.255, 172.16.0.0-172.31.255.255, and 192.168.0.0- 192.168.255.255. More information is available here.
Leave a Reply
Secure localhost, Server Name, Internal IP Address, Internal Domain, Sub-domain including Wildcard domain e.g., *.company.local Secure multiple servers using SAN values. Certificates valid up to 10 years. Install the same certificate on unlimited servers.
- Secure localhost, Server Name, Internal IP Address, Internal Domain, Sub-domain including Wildcard domain e.g., *.company.local
- Secure multiple servers using SAN values
- Certificates valid up to 10 years
- Install the same certificate on unlimited servers
- The certificate is issued with SecureNT Intranet Root & Intranet Intermediate CA chain. They are to be installed on each client’s machine.
- Fast Issuance, usually less than 24 hours
- Fast Expert Customer Support
- Automatic renewal reminders and early renewal options
- 30-day free certificate for Single Domain. 7-day free certificate for Multi-domain and Wildcard.
- Certificates with Custom Root CA in the name of your Organization are available
- Client Authentication Certificates for Web-based Applications and Document Management Systems available
Leave a Reply
TLD is the acronym used for top-level domain. It’s the last segment of a domain name after the final dot.
TLD is the acronym used for top-level domain. It’s the last segment of a domain name after the final dot.
A great example of a TDL is: .com
The IANA officially recognizes three types of TLDs:
- gTLD – Generic Top-Level Domains
- ccTLD – Country Code Top-Level Domains
- sTLD – Sponsored Top-Level Domains
Your TLD plays an important role in the Domain Name System (DNS). For more information click here.
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
Installation FAQ
This FAQ explains how to generate CSR on Microsoft Windows Server running IIS (any version) with SAN (Subject Alternative Name) values.
Following steps are applicable for all versions of IIS. Windows Server should be domain joined.
- Open the MMC console and add the Certificate snap-in to it as Local Computer. Right Click Personal node on the left and Select All Tasks –>Advanced Operations –> Create Custom Request.
- Choose Proceed without enrollment policy and Click Next. Choose No Template Legacy Key for compatibility reasons. Use PKCS#10.
- Click Next and click Properties. Give a friendly name for the certificate and a description. Ensure that you hit Apply as soon as you are done with the tab.
- Click on Subject tab and add all the hostnames under “Alternative Name“. Under Subject Name, enter the Common Name (CN), Organization (O), City (L), State (S) and Country (C) code (2 character) values. Click Apply.
- Under the Extensions tab, expand Extended Key Usage (application policies) and select Server Authentication and Client Authentication. Click Apply.
- Under the Private Key tab, set the Key size to 2048 under Key options. Tick Make Private Key exportable. Select Exchange as the Key type. Click Apply. Click OK.
- Select a location to save the file. Choose the file format as Base 64. Click Finish.
CSR is generated with SAN values.
Leave a Reply
Installation of SSL Certificate in Windows Azure environment is different. It requires a special password protected PFX file with Triple DES encryption. Please mention this requirement while placing request to us. We will send this special PFX file.
Installation of SSL Certificate in Windows Azure environment is different. It requires a special password protected PFX file with Triple DES encryption. Please mention this requirement while placing request to us. We will send this special PFX file.
Installation steps are given on this blog.
Leave a Reply
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
How to install or import PFX file with private key in IIS on Windows Server. Use ‘Certificates’ snap-in in MMC and Import. Next step is binding the certificate.
Step by step instructions on how to import the SecureNT Intranet SSL Certificate PFX file in Windows IIS Server (any version). It’s a two-step process.
Step-1: How to Import the PFX File in IIS
- From the Start menu, type MMC, and click OK
- In the User Account Control window, click Yes
- In the Console window, in the menu at the top, click File > Add/Remove Snap-in.
- In the Add or Remove Snap-ins window, under Available snap-ins click Certificates and then, click Add.
- In the Certificates snap-in window, choose Computer account and then, click Next.
- In the Select Computer window, select Local computer: (computer this console is running on), and then, click Finish.
- In the Add or Remove Snap-ins window, click OK.
- From the Console window, from the Console Root folder, expand Certificates (Local Computer) (the certificate file will be in Personal or Web Hosting folder).
- Right-click on the certificate file which you want to import and then click All Tasks > Import
- On the Welcome to the Certificate Import Wizard page, click Next.
- Follow the instructions to import the primary SSL certificate from the PFX file
- On the Certificate Store page, select Automatically select the certificate store based on the type of certificate.
- Double-check your settings and then click Finish
You should see “The import was successful” message.
Step-2: How to Enable the SSL Certificate
- From the start menu, search for Administrative Tools, open it, and double-click on Internet Information Services (IIS) Manager.
- Under Connections, expand your server’s name, expand Sites, and then, click the site that you want to encrypt.
- In the Actions menu, under Edit Site, click Bindings.
- In the Site Bindings window, click Add.
- In the Add Site Binding window, from the drop-down lists select: HTTPS, All Unassigned, and enter port 443.
- From the SSL certificate drop-down list, select the certificate you want to import
- Click OK and restart your IIS server
SecureNT Intranet SSL certificate is now installed on IIS.
Following article has the steps shown with screen-shots.
Leave a Reply
These steps tells how to install SecureNT Intranet SSL Certificate in Apache Web Server environment. Apache could be on any flavour of Linux or on Windows.
Follow these steps to install SecureNT Intranet SSL on Apache web server in Linux or Windows environment.
1. Copy the required certificate files to your server from the supplied zip file.
-
- server.cer (File #1)
- SecureNT CA-Bundle.cer (File #5)
- Copy these files, along with the .key file (Private Key) you generated when creating the CSR, to the directory on the server where you keep your certificate and key files. Use serverkey.cer (File #2, Private Key) when generated by SecureNT.
Note: Make them readable by root only, to increase security.
2. Find the Apache configuration file (httpd.conf) you need to edit.
The location and name of the configuration file can vary from server to server—especially if you’re using a special interface to manage your server configuration.
-
- Apache’s main configuration file is typically named httpd.conf or apache2.conf. Possible locations for this file include /etc/httpd/ or /etc/apache2/. For a comprehensive listing of default installation layouts for Apache HTTPD on various operating systems and distributions, see Httpd Wiki – DistrosDefaultLayout.
- Often, the SSL certificate configuration is located in a block in a different configuration file. The configuration files may be under a directory like /etc/httpd/vhosts.d/, /etc/httpd/sites/, or in a file called httpd-ssl.conf.
One way to locate the SSL Configuration on Linux distributions is to search using grep, as shown in the example below.
Run the following command:
grep -i -r “SSLCertificateFile” /etc/httpd/
Note: Make sure to replace /etc/httpd/ with the base directory for your Apache installation.
3. Configure the block for the SSL-enabled site
a. Below is a very simple example of a virtual host configured for SSL. The parts listed in blue are the parts you must add for SSL configuration.
DocumentRoot /var/www/html2
ServerName www.yourdomain.com
SSLEngine on
SSLCertificateFile /path/to/server.cer
SSLCertificateKeyFile /path/to/your_private.key
SSLCertificateChainFile /path/to/SecureNT CA-Bundle.cer
b. Make sure to adjust the file names to match your certificate files.
-
- SSLCertificateFile is your SecureNT certificate file (e.g., server.cer).
- SSLCertificateKeyFile is the .key file generated when you created the CSR (e.g., serverkey.cer or your_private.key).
- SSLCertificateChainFile is the SecureNT CA certificate file Bundle (e.g., SecureNT CA-Bundle.cer)
Note: If the “SSLCertificateChainFile” directive does not work, try using the “SSLCACertificateFile” directive instead.
4. Test your Apache configuration file before restarting.
As a best practice, check your Apache configuration file for any errors before restarting Apache.
Caution: Apache won’t start again if your configuration files have syntax errors.
Run the following command to test your configuration file (on some systems, it’s apache2ctl):
apachectl configtest
5. Restart Apache.
You can use apachectl commands to stop and start Apache with SSL support.
apachectl stop
apachectl start
Restart Notes:
If Apache doesn’t restart with SSL support, try using apachectl startssl instead of apachectl start. If SSL support only loads with apachectl startssl, we recommend you adjust the apache startup configuration to include SSL support in the regular apachectl start command. Otherwise, your server may require to manually restart Apache using apachectl startssl in the event of a server reboot. This usually involves removing the and tags that enclose your SSL configuration.
Leave a Reply
How to install SecureNT Intranet SSL Certificate in PFX format into the Tomcat Middleware on any Server OS. Keytool is used for the import.
Zip file sent by us has the server certificate (server.pfx) in PFX (PKCS12) format. It needs to be imported into the Tomcat/JBoss Keystore file.
To import the SecureNT Intranet SSL Certificate into the Tomcat/JBoss Keystore, use the following command.
keytool -importkeystore -deststorepass inetssl2 -destkeypass inetssl2 -destkeystore [tomcatjbosskeystorefile] -srckeystore server.pfx -srcstoretype PKCS12 -srcstorepass inetssl2 -alias [tomcat/jboss]
In the above command replace the [tomcatjbosskeystorefile] with the Tomcat/JBoss Keystore file you have on your computer.
Also Check: Tomcat keeps its configuration information in the server.xml file. Make sure Tomcat is reading the correct Tomcat/Jboss Keystore file and that port 8443 is enabled for secure connections.
Leave a Reply
How to install SecureNT Intranet SSL Certificate on XAMPP setup.
To proceed with the installation, you need to download the certificate zip file and extract its contents onto your device.
Step 1: Set up a Folder for Storing SSL Files
Create a new folder on your XAMPP server to store the SSL files. You will use this folder to store the SSL files for your XAMPP HTTPS setup. Unzip all files here.
Step 2: Locate the Configuration File for Your Localhost Website
There are two methods for finding the configuration file for your website:
Method 1:
Click Config in the XAMPP control panel and select Apache (httpd-ssl.conf).
Method 2:
Use the file explorer to find the configuration file located in the folder where you installed the XAMPP control panel.
Step 3: Edit the Virtual Host for Port 443
Open the configuration file in a text editor, such as Notepad, and make the necessary changes. Here’s an example of what the virtual host for port 443 should look like after editing:
DocumentRoot “/var/www”
ServerName intranet-common-name (e.g., localhost)
ServerAlias
SSLEngine on
SSLCertificateFile “D:/xampp/yourwebsite/ssl/server.cer”
SSLCertificateKeyFile “D:/xampp/yourwebsite/ssl/serverkey.cer”
SSLCACertificateFile “D:/xampp/yourwebsite/ssl/CA-bundle.cer”
Note: Remember to replace the server name, alias, and certificate paths with the actual values that apply to your setup. And copy the server.cer, serverkey.cer and CA-bundle.cer to the required path viz., D:/xampp/yourwebsite/ssl/
Step 4: Restart the Server
Finally, restart the server by clicking Stop in the XAMPP control panel, then Start. This will ensure that the new SSL certificate is properly applied.
Test your SSL Installation
After you install an SSL Certificate in XAMPP, you should test the certificate installation by visiting your intranet common name on the browser using https protocol.
Leave a Reply
One can use Microsoft Group Policy (GPO) to install SecureNT CA certificates on large number of PCs automatically
One can use Microsoft Group Policy to install SecureNT CA certificates on large number of PCs automatically. Here is link to our blog which explains how to do it.
Leave a Reply
This FAQ answers how to install SecureNT Root/Intermediate CA certificates on android devices including recent Samsung devices.
Please follow the below steps.
a. Android 11+ Device
In Android 11+, to install a CA certificate, users need to manually:
1. Open Device settings
2. Go to ‘Security’
3. Go to ‘Encryption & Credentials’
4. Go to ‘Install from storage’ or ‘Install a certificate’ (depending on devices)
5. Select ‘CA Certificate’ from the list of types available
6. Accept a warning alert.
7. Browse to the certificate file on the device and open it
8. Confirm the certificate installation
b. On recent Samsung device:
Settings
-> Biometrics and security
-> Other security settings
-> Install from device storage
-> CA Certificate
-> Install Anyway
Leave a Reply
Check this:
- Please check if you have installed Intranet Root/Intermediate CA Certificates on Windows PCs or Macs. If they are already installed then it could be an antivirus blocking access to the root certificate, thinking that is not a trusted root certificate. In this case, create an exception in the setting of the anti-virus to allow access to SecureNT Intranet root/intermediate CA certificates.
- On Windows PCs ensure that Intranet Root CA Certificate is installed under “Trusted Root Certification Authorities”; and that Intranet Intermediate CA Certificate is installed under “Intermediate Certification Authorities”.
To install the SecureNT Intranet Root/Intermediate CA Certificates follow the steps given here. They need to be installed once, on each Windows client PC. On a Mac, customers will need to open Keychain Manager and explicitly trust each of the two root certificates.
To automate the installation of root certificates on multiple machines, one can use Microsoft’s Group Policy for PCs; and Parallel’s Device Management for Macs. Click here to find the installation details. (https://intranetssl.net/support/resources/)
Firefox does not use the operating system’s certificate store for storing the root certificates. So, the root certificate chain is added differently. Read this article for details. (https://support.mozilla.org/en-US/kb/setting-certificate-authorities-firefox)
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
Even after the installation of root certificates on the client PC, the browser gives an error that the root certificate is not trusted. Here the culprit is antivirus or endpoint security software.
This sometimes happens due to Antivirus or End Point Security software. They don’t trust non-public Root Certificates and tell the browser that the Intranet Root Certificate is not trusted.
In one case, we noticed that AVG antivirus intercepted the network connection by keeping its own SSL in between, passing an error to the browser that SecureNT Root Certificate is not trusted. The customer created an exception for the error and the browser error stopped.
This problem is not seen with Avast antivirus. Just for information.
Leave a Reply