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!
Related
I am trying to establish node to node encryption. I am following datastax online guidance available for ssl encryption on below link- https://docs.datastax.com/en/security/5.1/security/secSetUpSSLCert.html
as per the documentation i have skipped first two steps and followed from step-3.
so, I have created the keystore, using below command-
keytool -genkeypair -keyalg RSA -alias node1 -keystore cassandra.jks -storepass cass123 -keypass cass123 -validity 365 -keysize 2048 -dname "CN=host1, OU=cluster1, O=org, C=US"
after creating the keystore, here the public certificate authority have two level of encryption or certs. first is root.cert and another is intermediate.cert.
when i have checked through below command, intermediate.cert is signed or verifyed by root.cert.
openssl verify -CAfile root.cert intermediate.cert , Got OK in Response.
after than with keystore(cassandra.jks), i have raise the certificate signed request (CSR):
keytool -keystore cassandra.jks -alias node1 -certreq -file cassandra.csr -keypass cass123 -storepass cass123 -dname "CN=host1, OU=cluster1, O=org, C=US"
then after uploading this CSR file (cassandra.csr) to public certificate authority i got in response one Cert.cer file.
so, then i checked whether the Cert.cer file get signed by root.cert or not.
openssl verify -CAfile root.cert Cert.cer
Got unable to load certificate in Response, with error message-
140044398696338:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c707:Expecting TRUSTED CERTIFICATE
Even I have Checked the Cert.cer with intermediate.cert-- got the same above error message.
Is this mean the Cert.cer which i got in response to csr request in not properly signed by certificate authority.
So i have stopped further steps here, which needed for cassandra ssl implementation.
Please, let me know, if i miss something or doing in wrong manner. much appreciated all help and suggestions
This issue is resolved, due to platform issue certs generated have extras carriage characters ^M. after removing this and merging root and intermediate certs together it works fine.
In my Azure Linux web app, I'm trying to perform an API call to an external provider, with a certificate. That call fails, while it's working fine when deploying the same code on a Windows app service plan. The equivalent cURL command line is:
curl --cert-type p12 --cert /var/ssl/private/THUMBPRINT.p12 -X POST https://www.example.com
The call fails with the following error:
curl: (58) could not load PKCS12 client certificate, OpenSSL error error:140AB18E:SSL routines:SSL_CTX_use_certificate:ca md too weak
The issue is caused by OpenSSL 1.1.1d, which by defaults requires a security level of 2, and my certificate is signed with SHA1 with RSA encryption:
openssl pkcs12 -in THUMBPRINT.p12 -nodes | openssl x509 -noout -text | grep 'Signature Algorithm'
Signature Algorithm: sha1WithRSAEncryption
Signature Algorithm: sha1WithRSAEncryption
On a normal Linux VM, I could edit /etc/ssl/openssl/cnf to change
CipherString = DEFAULT#SECLEVEL=2
to security level 1, but on an Azure Linux web app, the changes I make to that file are not persisted..
So my question is: how do I change the OpenSSL security level on an Azure web app? Or is there a better way to allow the use of my weak certificate?
Note: I'm not the issuer of the certificate, so I can't regenerate it myself. I'll check with the issuer if they can regenerate it, but in the meantime I'd like to proceed if possible :)
A call with Microsoft support led me to a solution. It's possible to run a script whenever the web app container starts, which means it's possible to edit the openssl.cnf file before the dotnet app in launched.
To do this, navigate to the Configuration blade of your Linux web app, then General settings, then Startup command:
The Startup command is a command that's ran when the container starts. You can do what you want, but it HAS to launch your app, because it's no longer done automatically.
You can SSH to your Linux web app, and edit that custom_startup.sh file:
#!/usr/sh
# allow weak certificates (certificate signed with SHA1)
# by downgrading OpenSSL security level from 2 to 1
sed -i 's/SECLEVEL=2/SECLEVEL=1/g' /etc/ssl/openssl.cnf
# run the dotnet website
cd /home/site/wwwroot
dotnet APPLICATION_DLL_NAME.dll
The relevant doc can be found here: https://learn.microsoft.com/en-us/azure/app-service/containers/app-service-linux-faq#built-in-images
Note however that the Startup command is not working for Azure Functions (at the time of writing May 19th, 2020). I've opened an issue on Github.
To work around this, I ended up creating custom Docker images:
Dockerfile for a webapp:
FROM mcr.microsoft.com/appsvc/dotnetcore:3.1-latest_20200502.1
# allow weak certificates (certificate signed with SHA1)
# by downgrading OpenSSL security level from 2 to 1
RUN sed -i 's/SECLEVEL=2/SECLEVEL=1/g' /etc/ssl/openssl.cnf
Dockerfile for an Azure function:
FROM mcr.microsoft.com/azure-functions/dotnet:3.0.13614-appservice
# allow weak certificates (certificate signed with SHA1)
# by downgrading OpenSSL security level from 2 to 1
RUN sed -i 's/SECLEVEL=2/SECLEVEL=1/g' /etc/ssl/openssl.cnf
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.
I would like to connect to a hive service running on BigInsights from a spark notebook using jdbc. The jdbc url format is:
jdbc:hive2://${env.hostname}:10000/default;ssl=true;sslTrustStore=./truststore.jks;trustStorePassword=mypassword;
As you can see from the url, this connection requires a truststore. How should I make the truststore available to spark as a service?
Update 1:
The certificate is not issued by a well known CA.
Tenants have no access to the JRE/JDK on the service.
Update 2:
I can add the certificate and truststore using the following:
with open('certificate', 'w') as f:
f.write('''
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
''')
!keytool -import -trustcacerts -alias biginsights -file certificate -keystore truststore.jks -storepass mypassword -noprompt
The final part of the question now is how to add a jar to python notebook on bluemix spark?
Here is one of the may be odd way around(Not tried):-
In Notebook, If you are already not in python shell, then switch to python shell and then if you have your truststore available to be downloaded from URL , you can download it this way and run cell:-
!wget
if biginsights server lets you use SSH to access the keystore, use !scp to download the truststore.
Once downloaded, i would suggest try to use
!pwd which will give you path
/gpfs/fs01/user/s027-20bcfe6e4297e8-2c631c8ff999/notebook/notebooks
If you do !ls, you can see your downloaded trustore file.
See if you can give the FULL Absolute path to trustore in JDBC URL.
Thanks,
Charles.
First find out if the SSL certificate is issued by a "well-known" CA authority. By "well-known", I meant those CA authorities whose signing certificates are already included in the jdk truststore. If yes, find out from the jdk documentation the location and name of the truststore and provided that in the sslTrustStore parameter. If no, then has to download the cert, add to a truststore and upload the truststore to a location accessible by spark as a service.
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/