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
Related
I have an Azure Application GateWay listening to 443 and redirecting traffic to
3 VM (ubuntu) listening to port 80 with nginx has reverse proxy, which redirect to pm2 node server, this is for Server Side Rendering with Angular Universal
When I create a new Listener in the Application Gateway I upload the pfx file
Now when I browse my sites I get a secure connection, but when I try to share a url in social media like facebook, twitter or linkedin I get an error with the certificate, so images and keywords are not displayed
I found this site that allows me to check SSL configurations (https://www.sslshopper.com/ssl-checker.html), the results shows that I´m missing the intermediate certificate
If I install the SSL into a VM without the Application Gateway and redirect clients to that VM, then everything works great.
I have been changing Listeners, Rules and even try SSL Settings which is in preview, but no luck so far
Any idea what am I missing ?
Thanks in advance
Hope this helps somebody else. There are some SSL providers that do not include the intermediate certificate in the .pfx file, so you have to do this yourself in order to make it work in Azure Application Gateway. Steps are really simple:
Install OpenSSL (Yes, even if you buy the SSL)
Download the files(.key, .crt, .ca.crt) from your provider into a folder
Execute this command: openssl pkcs12 -export -out [certificate-name].pfx -inkey [certificate-name].key -in [certificate-name].crt -certfile [certificate-name].ca.crt , this will include the intermediate certificate into your .pfx file
Upload the .pfx file to your application gateway
I want to use Azure Application gateway for TLS termination. When trying to upload my PFX certificate to an Application Gateway Listener I receive the following, non-informative, error message:
Failed to save application gateway changes
Failed to save configuration changes to application gateway 'main-backend'. Error: Data must be specified for Certificate main-backend/cert4.
I am using a certificate issued by LetsEncrypt and converted to PFX using openssl. The certificate file looks proper the certificate password I passed to Azure is the right one.
Can someone tell me what's the issue here? Thank you!
See SSL Cert Error in Azure Application Gateway for similar discussion.
My experience aligned with that discussion: the certificate just seemed to take a little while to deploy. No issues beyond the "disappearing rule" described there. Recreated the rule after a little while (and updated NSG to allow incoming on 443) and it flowed to backend pool (in my case: TLS offload on Gateway to HTTPS on backend).
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
I am creating a VPN in Azure, and created self-signed certificate in the following places:
Local Computer:
Personal/Certificates: Issued To: FQDN name is the certificate's name
Trusted Root Certification Authorities/Certificates:
manually copied from Personal
I have configured the VPN in Azure and it is downloaded and extracted and the vpn client is installed successfully, however, when I run the client I received the following error:
A certificate could not be found that can be used with this Extensible
Authentication Protocol. (Error 798)
Screenshot:
The error seems suggesting the certificate is NOT found, does the name matter?
Should I change the cert's name from Azurecert to FQDN which is the name in my local computer?
Thank you for your help in advance.
UPDATE:
I removed the existing certification in Azure's configuration and re-added back with the same FQDN name shown in local computer's certificates, I redownloaded the client, I removed the existing installed vpn client and re-installed the new one, I receive the same error message. So it seems name is not the root cause?
UPDATE2:
The procedure I've followed:
Create Self Signed Certificate with the FQDN name on local laptop;
New-SelfSignedCertificate –DnsName NV-RXIE.novantas.pri -CertStoreLocation “cert:\LocalMachine\My”
Add the self-signed certificate as a trusted certificate authority, Copy the new cert to Trusted Root Certificate Authorities
export the cert and open it, copy the cert part and paste into the
VPN setting – Root certificates, Public Certificate Data
Download the VPN client and install it on laptop, run it
Connect, failed with:
A certificate could not be found that can be used with this Extensible
Authentication Protocol. (Error 798)
When you try to connect to an Azure virtual network by using the VPN client, except for exporting the root certificate public key .cer file to Azure, each client computer that connects to a VNet using Point-to-Site must have a client certificate installed. You generate a client certificate from the self-signed root certificate and then export and install the client certificate. If the client certificate is not installed, authentication fails.
This problem occurs if the client certificate is missing from Certificates - Current User\Personal\Certificates.
You could follow this solution to fix this issue. For more information about how to install the client certificate, see Generate and export certificates for point-to-site connections.
In case anyone runs into this issue at some stage, I had installed a new root cert that worked for 2 out of 3 VPN gateways fine. The third kept giving a 798 error even though the certs were correct and in the right place.
To fix the Error 798, I did the following:
reset the gateway in Azure Portal. (support & troubleshooting on VPN gateway blade)
remove the VPN configuration from my pc (win10)
reboot pc (just to be safe)
download and reinstall the VPN client from the Azure Portal again (from Point-to-site configuration on Azure VPN gateway in question)
Once done, I could then connect without any issues. Tested on several different users.
My guess is that if you are adding / removing the Root certs it might need you to reinstall the VPN client on your computer after the gateway has the new root cert configuration.
Hope that helps.
In addition to the answer by Nancy Xiong:
If you are still having problems with this error you can try the following
Run certmgr.msc
Go to Personal->Certificates
Right-click your certificate
All Tasks->Export
Choose Yes: Export private key
Accept default options until you reach a step where you must enter a password
Enter a password, and continue until you have exported your certificate
Repeat this process if you have more than one certificate
Locate your certificates in the Windows file explorer
Right-click->Install
Select Current User for the Store Location
Accept default options, and enter the certificate password when prompted
When asked which Certificate Store to place the certificate in, select Place all certificates in the following store
Click 'Browse' and select your Personal store
This should now work.
In rare circumstances you may find that this solution will only work for a short time (usually failing the next time you reboot). In this case you may need to follow these additional steps
Boot your computer into BIOS Configuration
Disabled any settings for Intel VTX and Intel VTD
Restart your computer
Retry the steps above
In addition to the answer by Peter Morris, I have did the below mentioned steps which helped in resolving this issue.
Delete the client certificate from your PC. This can be done by searching Manage User Certificates right click on the certificate -> Delete
Now, Reinstall your certificate, Accept default options, and enter the certificate password when prompted.
When asked which Certificate Store to place the certificate in, select Place all certificates in the following store
Click 'Browse' and select your Personal store
Accept all the default options which comes next and click finish.
The above steps helped me to resolve this issue
For me, I got this error because my previous cert has expired after 1 year.
I just deleted the old cert and followed this to create a new one:
https://learn.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-certificates-point-to-site
I am trying to create a new Let's Encrypt SAN certificate using the Certes Library and hosting on a Azure WebRole. Everything has worked previously (many times) but now I am getting a cert error on Android and ssllabs.com shows a certificate chain incomplete error.
The certificate is created without error and I have explicitly set FullChain = true on the PfxBuilder but I am unsure how to check if the full chain is recorded in the certificate correctly without uploading the certificate together with a new deployment (I am not a cert expert).
On the Azure Web role both the created certificate and the required Let's Encrypt Cert (Let's Encrypt Authority X3) are listed in the webrole certificates. I only uploaded the created certificate Azure adds the Let's Encrypt Authority X3 cert itself.
I am unsure whether it is a problem with the certificate not recording the full chain or some configuration setting on the WebRole. When I go to Certificates in the Azure Management console I see the Let's Encrypt Cert but when I rdp into the role and look in the IIS Manager I cannot see the Let's Encrypt Cert under Server Certificates. I also cannot find it when I open the Certificates Management Console (certlm).
I am starting to think it is a problem with the WebRole but I am at a loss on what to check next.
You need to add additional <Certificate> element in your ServiceDefinition and ServiceConfiguration to specify the intermediate certs. See https://blogs.msdn.microsoft.com/azuredevsupport/2010/02/24/how-to-install-a-chained-ssl-certificate/
Edit due to broken link
View your certificate. For each of the intermediate certificate between the root cert and your certificate, export the certificate file.
Upload these certificate to Azure
Add the <Certificate> element. You can get the thumbprint from the Azure portal.