I have a software running on my server which is called Gitlab. The service is accessible through a SSH, HTTP and a HTTPS endpoint. All three access points are reachable through a SSH tunnel, so binded to 127.0.0.1.
> 127.0.0.1:80 # HTTP
> 127.0.0.1:443 # HTTPS
> 127.0.0.1:1234 # SSH
To enable HTTPS, I created my own SSL certificate but of course there is no authority which confirms its authenticity. So even if I satisfy my server to work with it, I am wondering if I should even continue using it.
There are a lot of services on the server, or client tools which connect to it, and all would need to respect their system keychain where the public key is stored in as "trustworthy". Does anyone have experience with this constellation?
Using a self-signed certificate is the default configuration, to speed up the startup process, and it's up to you to decide if you want to install a trusted certificate from a third party CA, or a local CA (maybe your AD integrated CA). If a service is local or internal to your company, you can decide to keep it self-signed.
In the environments i was involved with, there was a AD integrated CA and we signed everything with that.
Further informations: https://docs.gitlab.com/ee/user/project/pages/custom_domains_ssl_tls_certification/ssl_tls_concepts.html
Related
I have a webapp server based on nodejs installed on Windows Server 2016. I want to install an SSL Certificate on such server. I've generated a free SSL from Cloudflare but it downloaded a DER file. The person responsible for configuring the Webserver said he needs a .pfx and a passphrase in order to install the SSL Certificate. Is there a way to convert .der to .pfx with a passphrase, or is there any other way to do that for free or buy one at a very low cost,
Thanks in advance!
If you need a custom SSL certificate for you server, consider obtaining it directly from Let's Encrypt https://letsencrypt.org/.
Alternatively, you can use Cloudflare as a reverse proxy on top of your Node.js server that will add SSL automatically without a need to configure anything (other than creating a DNS record and checking "Cloudflare Proxy" (orange) checkbox. Then in your server settings, you would just configure firewall rules to allow connections only from Cloudflare IPs that can be found here — https://www.cloudflare.com/ips/.
I'm using an Azure Application Gateway v2 to route traffic to a backendpool containing VMs running some docker container hosting an aspnet core webapi. The application is listeing in port 443.
The gateway listener is configured to accept HTTPS connections. A pfx certificate has also been added.
The HTTP setting of the gateway is configured as follow:
I've provided, hopefully, the correct root certificate for the setting. I've exported the certifacte as described here:
https://learn.microsoft.com/de-de/azure/application-gateway/certificates-for-backend-authentication
All VMs from the backend pool use the same certificate as the gateway listener.
When calling the api using a C# application or open a specific url within a browser, the connections seems to be trusted.
But I get an error when calling the api using postman with endabled SSL cerificate verification.
Error: unable to verify the first certificate
A check on sslhopper.com also indicates an issue within the chain.
I got further information doing a chekc on digicert.com.
TLS Certificate is not trusted
The certificate is not signed by a trusted authority (checking against Mozilla's root store). If you bought the certificate from a trusted authority, you probably just need to install one or more Intermediate certificates. Contact your certificate provider for assistance doing this for your server platform.
I'm really stuck in resolving the issue. All helpful hints are very welcome.
The production environment, running on a Windows Server, wihtout the Gateway but the same certificates is valid. So the issue must be somewhere in the gateway configuration.
The issue is resolved. The crucial clue was delivered from a blog post.
http://blog.repsaj.nl/index.php/2019/08/azure-application-gateway-certificate-gotchas/
Gateway V2: the importance of the certificate chain
I did a new export of the pfx certificate including the whole chain and uploaded it to the gateway.
If the cert is not trusted, then you need to check the Application Gateway Listener. Make sure that you are not using Basic listener.
If you are using multi-site listener, make sure that the host name which you have mentioned matches with the certificate CN
The scenario is to test Broken Chain certificate. I have a Broken Chain Certificate by removing Intermediate Certificate(merged Server, Issuing, Intermediate and Root information into single .pem file, removed Intermediate information from it and converted it to .pfx) and uploaded it to Application Gateway. But when I am hitting the URL in browser or running OpenSSL show cert command, I am unable to see Broken Chain information. Had restarted Application Gateway too.
I am sure it is not getting downloaded from my Certificate Authority AIA folder as I have renamed it.
Does Application Gateway caches the certificate information by downloading it from Certificate Authority AIA folder and keeps on using the same information?
I think you need to open port 80 in outbound. a server will communicate with intermediate CA to validate the certificate
I have developed a RESTful web service using Node.js. I want to host this service on my home PC which is having static IP(which can be access from internet). But I want to host this service using SSL. Note that my home PC is not associated with any internet domain. So I want to know how to host my Webservice using ssl on my home PC. Also I want to know where to buy ssl certificate and what type of certificate? Because most of the certificate authorities who sells certificate talking about ssl for website only.
I've found some tutorials about transferring SSL from Windows to Linux server such as this one here: https://major.io/2007/03/23/exporting-ssl-certificates-from-windows-to-linux/. But is it possible to do something like this in shared hosting because in shared hosting Apache configuration may not be allowed?
Well it is possible to transfer an SSL certificate from a Windows (IIS) environment to a Linux (Apache) environment. Within a shared hosting environment, (at least the majority of them) it will not be possible to install the SSL certificate to the hosting account without the help of your hosting provider. The SSL installation requires an IP be allocated to your domain within the server's configuration, unless deployed with SNI, and a VirtualHost entry routing requested to port 443 (TLS/SSL) for your domain on that IP will have to be created. Needless to say these configurations affect the server as a whole and are chargeable services so most providers will not provide you direct access to do this. If your provider uses Plesk or cPanel or Vdeck then this is the case.
That being said it is well worth the money to have your hosting provider complete this configuration for you and the related services are generally pretty cheap. Most providers will average around $20.00 per year for all the services required to have your SSL function on their servers.
I would request information from your provider regarding the installation to see if it is the right solution for you.
As a note Windows (IIS) SSL certificates are commonly PKCS#12/PFX Formated. The PKCS#12 or PFX format is a binary format for storing the server certificate, any intermediate certificates, and the private key in one encryptable file. PFX files usually have extensions such as .pfx and .p12. PFX files are typically used on Windows machines to import and export certificates and private keys. Linux (Apache) will use PEM formatted certificates.The PEM format is the most common format that Certificate Authorities issue certificates in. PEM certificates usually have extentions such as .pem, .crt, .cer, and .key. They are Base64 encoded ASCII files and contain "-----BEGIN CERTIFICATE-----" and "-----END CERTIFICATE-----" statements. Server certificates, intermediate certificates, and private keys can all be put into the PEM format.
Apache and other similar servers use PEM format certificates. Several PEM certificates, and even the private key, can be included in one file, one below the other, but most platforms, such as Apache, expect the certificates and private key to be in separate files.
I would not bother with the conversion prior to contacting your hosting provider as they can obtain the PKCS#12/PFX certificate from you and then covert it when installing it on the server. You should only have to provide the PKCS#12/PFX formatted certificate.
Well instead of transferring the certificates its easy to reissue the SSL after you have migrated to another hosting platform.
In Shared hosting, you won't have access to the webserver (IIS and Apache) to export and import SSL Certificates. For that, you will have to contact your hosting service provider to transfer the SSL Certificate.
Recently, I've moved SSL Certificate from my Windows VPS to Linux VPS with the help of the following article.
https://www.sslsupportdesk.com/move-certificate-iis-apache/
I am sure that the above link will be helpful if you want to move the SSL Certificate from Windows VPS to Linux VPS.