Certificate Chain Failing and getting 502 Bad Gateway - azure

I have been given a certificate.crt, intermediate.crt, root.crt and a private key. I created a new certificate file by merging the intermediate and root together and I have run the following command to convert them into a PFX which seems to have worked.
openssl pkcs12 -export -out certificate.pfx -inkey private.key -in certificate.crt -certfile rootca.crt
I have then uploaded the PFX to an Azure application gateway. When I attempt to go to the URL, I get the following error 502 Bad Gateway.
When checking the health of the gateway I get the following error:
The root certificate of the server certificated used by the backend does not match the trusted root certificate added to the application gateway. Ensure that you add the correct root certificate to whitelist the backend.
The issue I'm having is that I do not have access to the Linux backend server and I'm not confident with Linux either, so I am not sure whether the certificate has been created correctly on the backend. My question is, have I created the certificate correctly using the OPENSSL command mentioned above?

I tried to reproduce the same issue in my environment and got the expected results.
Created the certificates using PowerShell commands given below
Step-1
$cert = New-SelfSignedCertificate -Type Custom -KeySpec Signature `
-Subject "CN=P2SRootCert" -KeyExportPolicy Exportable `
-HashAlgorithm sha256 -KeyLength 2048 `
-CertStoreLocation "Cert:\CurrentUser\My" -KeyUsageProperty Sign -KeyUsage CertSign
Step-2
New-SelfSignedCertificate -Type Custom -DnsName P2SChildCert -KeySpec Signature `
-Subject "CN=P2SChildCert" -KeyExportPolicy Exportable `
-HashAlgorithm sha256 -KeyLength 2048 `
-CertStoreLocation "Cert:\CurrentUser\My" `
-Signer $cert -TextExtension #("2.5.29.37={text}1.3.6.1.5.5.7.3.2")
After Running the commands the certificate will be created as below
Click Windows + r and run the below command → Click Ok
certmgr.msc
Goto → Personal → certificates→ Right click on the certificate you want to export and Goto All tasks as below
We need both CER & PFX certificated to be exported
For CXR certificate after clicking on Export→Next→ Select No→Select Base-64 encoded x.509(CER) click on Next→Select folder location and folder name → Clik on finish.
For PFX certificate after clicking on Export→Next→Select Yes→ Select Export all extended properties with other options by default click on Next→Click on Password Checkbox and enter the password Click on Next→Select folder location and folder name → Click on finish
I have created the application gateway and I have imported the certificate
I am able to access the URL.
Reference taken from MS-Doc

Related

Include Letsencrypt Root certificate in Azure Application Gateway

I'm trying to folllow Azure Tutorial on how to get Api Management under a vnet and accessible through an application gateway (WAF). I'm stuck trying to upload the root cert into application gateway. It says that the "Data for certificate is invalid", apparently Azure Application gateway doesn’t like Letsencrypt certs.
My certs are:
mydomain.com.br
api.mydomain.com.br
developer.mydomain.com.br
managemnet.mydomain.com.br
I have used acmesh to generate all certs:
./acme.sh --issue -d mydomain.com.br --dns dns_gd --server letsencrypt
./acme.sh --issue -d api.mydomain.com.br --dns dns_gd --server letsencrypt
./acme.sh --issue -d developer.mydomain.com.br ---dns dns_gd --server letsencrypt
./acme.sh --issue -d management.mydomain.com.br --dns dns_gd --server letsencrypt
Vnet, Subnets, Security Groups and Api Management are all created successfully, all good except for the part I need to create the application gateway:
$appgwName = "apim-app-gw"
$appgw = New-AzApplicationGateway -Name $appgwName -ResourceGroupName $resGroupName -Location $location `
-BackendAddressPools $apimGatewayBackendPool,$apimPortalBackendPool,$apimManagementBackendPool `
-BackendHttpSettingsCollection $apimPoolGatewaySetting, $apimPoolPortalSetting, $apimPoolManagementSetting `
-FrontendIpConfigurations $fipconfig01 -GatewayIpConfigurations $gipconfig -FrontendPorts $fp01 `
-HttpListeners $gatewayListener,$portalListener,$managementListener `
-RequestRoutingRules $gatewayRule,$portalRule,$managementRule `
-Sku $sku -WebApplicationFirewallConfig $config -SslCertificates $certGateway,$certPortal,$certManagement `
-TrustedRootCertificate $trustedRootCert -Probes $apimGatewayProbe,$apimPortalProbe,$apimManagementProbe
The last line is where I need to inform the path to my .cer file. I have tried to add the mydomain.com.br.cer and fullchain.cer, no luck. Tried to use openssl to create a Base64 file, also no luck:
sudo openssl x509 -inform PEM -in /etc/letsencrypt/live/mydomain.com/fullchain.pem -outform DER -out trustedrootDER.cer
openssl x509 -inform der -in trustedrootDER.cer -out trustedroot.cer
I even created a VM running Windows to try this approach, no joy.
The solution from the Architecture point of view is pretty simple, but the certs problem makes it troublesome:
Any direction here is much appreciated!
Thanks
Why you want to add the Lets Encrypt Root CA cert on your application gateway?
From my understanding the Root CA from Lets Encrypt is ISRG Root X1 and this one should be already trusted by Clients (Browsers).You only want to add the Root CA if you have self signed certificates.
Here is a workflow with storing the certs in Azure Key Vault: https://techblog.buzyka.de/2021/02/make-lets-encrypt-certificates-love.html
Another Workflow here describes adding certs with ACME challenges: https://intelequia.com/blog/post/1012/automating-azure-application-gateway-ssl-certificate-renewals-with-let-s-encrypt-and-azure-automation

How renew ssl certificate on Tomcat?

Following the go-daddy documentation :
https://www.godaddy.com/help/tomcat-4x5x6x-renew-a-certificate-5355
The flow:
I've create myDomain.csr and send it to GoDaddy , got reply from them with 3 files ( gd_bundle-g2-g1.crt , gdig2.crt.pem ,59a41eaec32d2046.crt)
I mentioned that the old cert which was expired has a chain structure , unfortunately Go-daddy give me only "flat" certificates.
I tried to make a chain by myself :
cat 59a41eaec32d2046.crt gd_bundle-g2-g1.crt gdig2.crt.pem >> myDomain.crt
after that :
sudo keytool -import -alias tomcat -keystore tomcat.keystore -trustcacerts -file myDomain.crt
sudo keytool -import -alias intermed -keystore tomcat.keystore -trustcacerts -file gdig2.crt
sudo keytool -import -alias root -keystore tomcat.keystore -trustcacerts -file gd_bundle-g2-g1.crt
and change the server.xml exactly as in the documentation
I Attach pictures of how in my opinion it should appear
But Actually after my chain I had :
When I open the Browser GOT:
Secure Connection Failed
An error occurred during a connection to talenttribe.me. Cannot communicate securely with peer: no common encryption algorithm(s). Error code: SSL_ERROR_NO_CYPHER_OVERLAP
The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
Please contact the website owners to inform them of this problem.
Learn more…
Report errors like this to help Mozilla identify and block malicious sites
Don't understand what I'm missing...is it Chain creation or tomcat issues ??
BR,
You just need to replace tomcat certificate if your renew from existing vendor.
certificate name hexcode.crt Other no need to change. Its works for me.
keytool -import -alias tomcat -keystore tomcat.keystore -trustcacerts -file filepath
The issue is that the tomcat.keystore is not being created with chaining intact. To correct that, you will need to isolate the root and intermediate certificates in separate files, and then import them in a specific order. To create a working example, here are some simplifying assumptions:
The 59a41eaec32d2046.crt file contains only the SSL certificate issued by Go Daddy, presumably for an internet facing web server.
The "gd_bundle-g2-g1.crt" file is a concatenation of the Go Daddy intermediate and root certificates.
The "gdig2.crt.pem" file contains a redundant copy of the Go Daddy root certificate.
There is only one intermediate certificate, and it is also the Issuer of your SSL certificate.
The crt files are the base 64 encoded, or "pem", format.
The tomcat.keystore file uses JKS format.
Here are the steps to create the tomcat.keystore, given the assumptions above:
List the contents of gd_bundle-g2-g1.crt:
sudo keytool -printcert -file gd_bundle-g2-g1.crt
The output will include delimiters for each certificate in the bundle. The delimiter for the first certificate will be "Certificate[1]:", and the delimiter of the second certificate will be "Certificate[2]:". Immediately following "Certificate[1]:", you will see the Owner and Issuer records for the first certificate. Likewise, following "Certificate[2]:", you will see the Owner and Issuer records for the second certificate. Also note:
The root certificate is unique in that the Owner is the same as the Issuer (in other words, it is self-signed).
The root certificate is also the Issuer of the intermediate certificate.
List the contents of gd_bundle-g2-g1.crt in "rfc" format:
sudo keytool -printcert -file gd_bundle-g2-g1.crt -rfc
Again, note the delimiters "Certificate[1]:" and "Certificate[2]:" are used with the same meaning as above. But in rfc format, the certificates are listed using base 64 "pem" format starting with "-----BEGIN CERTIFICATE-----" and ending with "-----END CERTIFICATE-----". That is format that will be needed in the separate root and intermediate certificate files.
Redirect the output of step 2 to a temporary file. Then use a text editor to save the Go Daddy root certificate in a separate file named gd_root.crt.
Be certain to include the entirety of the text beginning with "-----BEGIN CERTIFICATE-----" and ending with "-----END CERTIFICATE-----".
Likewise, save the Go Daddy intermediate certificate in a separate file named gd_intermediate.crt.
Use the "keytool -importcert" command to create the keystore incrementally:
sudo keytool -importcert -noprompt -file gd_intermediate.crt -alias intermed -keystore tomcat.keystore -storepass '!q#wDDfll'
sudo keytool -importcert -noprompt -file gd_root.crt -alias root -keystore tomcat.keystore -storepass '!q#wDDfll'
sudo keytool -importcert -noprompt -file 59a41eaec32d2046.crt -alias tomcat -keystore tomcat.keystore -storepass '!q#wDDfll'
The order of the commands above is important. You need to create the keystore first using the intermediate certificate used by the CA to issue (sign) your SSL certificate. (If there are additional intermediate certificates, those would be added next, until the final intermediate certificate, which is signed by the root certificate, is added.) Next, you add the root certificate. And finally, you add the SSL certificate issued by the CA for your application.
This will fix the issue with the tomcat.keystore file. You might also consider building a custom trust store file, which requires the truststoreFile and truststorePass options within the connector element, as an alternative to relying on Java's cacerts trust store. The commands to do that are similar to the fist 2 commands above, substituting the trust store file name along with the trust store password.

SSL certificate is not installing

I'm facing an issue in installing SSL certificate in IIS and below are the step before I got the certificate from my CA.
Generated a private key file using OpenSSL with: "openssl genrsa -out key_name.key 2048" command.
Generated .csr file with: "openssl req -out CSR.csr -key key_name.key -new -sha256" command.
Once I generated the CSR file, I provided the same CSR file to CA to get me certificate.
I got the certificate in .p7b format, which I converted to .cer format.
Installed certificate using "Complete certificate request" option in IIS.
Now the problem is that newly installed certificate vanishes from IIS after a refresh. I Googled this issue and understood that, it's happening so because there is no private key associated with certificate. My question is where the private key has gone?? I had created the CSR using the private key in step 1. Secondly, how do I over come this issue, I have to install the certificate anyhow. Please help.
You did not generate the certificate request via IIS Manager. Thus, you should not use IIS to complete the request.
Instead, you need to use OpenSSL to generate a PFX file,
create a pfx file from a .cer and a .pem file
Then you can import it to IIS.
You might read this post for more details,
https://blog.lextudio.com/2015/06/the-whole-story-of-server-certificate-disappears-in-iis-77-588-510-0-after-installing-it-why/

TeamCity build agent becomes disconnected after adding self-signed https certificate to teamcity

I added a self-signed certificate to my Teamcity BuildServer to introduce https support so that it can now be accessed at
https://ServerUrl:8443
(More details about how here )
The result was that I was able access the server via https, but my build agent was now disconnected. How to fix this?
The build agent works as a client to the build server and communicates with it using http/https, and it turns out that when you add a self-signed certificate the build agent does not accept it.
I needed to
Let the build agent know the new path for communicating with the server
Let the build agent know that it could trust the self-signed certificate
To change the path I did the following (see this post for more details )
Locate the file:
$TEAMCITY_HOME/buildAgent/conf/buildAgent.properties
Change the property
serverUrl=http:\://localhost\:8080 to your new url
To let the build agent know that it could trust the new certificate I had to import it into the build agent's key store.This was done using keytool:
keytool -importcert -file <cert file>
-keystore <agent installation path>/jre/lib/security/cacerts
( unless you've changed it, the keystore is protected by password: changeit)
The TeamCity team describes this process in slightly more details here
NOTE
If you need to retrieve your certificate from the TeamCity buildserver keystore, you can also use keytool to do this :
keytool -export -alias <alias name>
-file <certificate file name>
-keystore <Teamcity keystore path>
Here is a link to the TeamCity v8 documentation on the keytool.
I was doing this on a Windows Build Agent and had a self-signed SSL cert on my Amazon Linux Build Server. Here were the steps I took:
Went to build server in browser on Build Agent i.e. https://teamcity.example.com
Clicked on the certificate error in the URL and downloaded the cert to the local machine
Exported the certificate from the certificate explorer in windows into a cer file.
Used the keytool exactly as specified in the documentation
> keytool -importcert -file <cert file where it was exported to>
-keystore <path to JRE installation>/lib/security/cacerts
password: changeit
Restarted the build agent and viola!

(Internal)CA signed certificate on WebLogic & same CA cert(public key) on my machine. Browser still doesn't trust

Created Private Key & Self signed certficate in a Key Store
keytool -genkey -alias mydomain -keystore mydomain.ks -dname cn=mydomain.com -keyalg RSA -sigalg SHA1withRSA
Created Certificate Request and sent to Internal CA
keytool -certreq -alias mydomain -keystore mydomain.ks -file mydomain_project.csr
Once Internal(Company) CA issues the certificate - which looks like something like this
e.g.
-----BEGIN CERTIFICATE-----
MIAGCSqGSIb3DQEHAqCAMIACAQExADALBgkqhkiG9w0BBwGggDCCAmowggHXAhAF
UbM77e50M63v1Z2A/5O5MA0GCSqGSIb3DQEOBAUAMF8xCzAJBgNVBAYTAlVTMSAw
E+cFEpf0WForA+eRP6XraWw8rTN8102zGrcJgg4P6XVS4l39+l5aCEGGbauLP5W6
-----END CERTIFICATE-----
Copied this to a .pem file
Update the self signed certifcate in (identity) KeyStore with CA signed certificate & Created a new Java Key Store(Trust) CA signed certificate(using the .pem file)
keytool -import -alias mydomain -trustcacerts -file company_cert.pem -keystore mydomain.ks
keytool -import -alias mydomain -trustcacerts -file company_cert.pem -keystore trust.jks
On Weblogic I imported the keystores as follows and Enabled SSL.
Identity - mydomain.ks (with Private Key + CA certificate)
Trust - trust.jks (which has CA certificate)
Issue: Once I hit my internal site deployed on the weblogic. I get a message - Not a trusted certificate.
I then download the certifcate from the browser only then https works.but the certificate shows it is signed bythe domain name I gave, instead of my Internal CA name.
Question: I expected it to work(with out actually downloading again) as I already have Internal CA certificates and other internal applications work on https. Did I do any thing wrong?
I am not sure how/where you imported the certificate as you say but the browser has a different truststore than java.
So you have to add it as an exception to its truststore the first time you access the site.
As far as the domain name that is displayed the browser pops up the certificate as send by the server
I solved my problem. Thanks user384706.
Basically once you get a signed .pem file(with START & END) from CA.
Before you import this signed certificate to replace the self-signed in your keystore(Identity Keystore to be configured on WebLogic). We need to make sure
1) CA root certificates(Verisign's or your company signed CA certificates) are imported to the same Keystore. You can find CA root certs on your windows box (run-certmgr.msc).
2) Also make sure that all these alias names are the same -
self-signed cert
cert request
while importing CA cert

Resources