I have an existing spring webapp which uses SAML to let users login via a third party site. Users login on the third party site and use SAML to single-sign-on into my application. The third party site recently had their certificate expire and they sent me a new .crt file to import into my java keystore. I used the following commands to update my java keystore:
keytool -delete -alias thirdPartyCertificate -keystore myKeystore.jks
keytool -import -trustcacerts -alias thirdPartyCertificate -file 2017-third-party-certificate.crt -keystore myKeystore.jks
Both commands completed successfully (and I can run a -list on the keystore and see that the new certificate is present and not expired). However, after I restarted my java webserver, the single sign on did not work. It threw the following two warnings and then failed to login the user:
WARN org.opensaml.common.binding.security.BaseSAMLSimpleSignatureSecurityPolicyRule - Simple signature validation (with no request-derived credentials) failed
WARN org.opensaml.common.binding.security.BaseSAMLSimpleSignatureSecurityPolicyRule - Validation of request simple signature failed for context issuer: <certificate_url_omitted>
What would cause the certificate validation to fail? I don't think that their certificate is bad because several other webapp maintainers were able to successfully use the new certificate. Is there some step that I missed in installing the new certificate?
You will need to set the signingKey property to alias of the certificate you imported in the ExtendedMetadata of your IDP. See https://docs.spring.io/spring-security-saml/docs/1.0.x-SNAPSHOT/reference/htmlsingle/#configuration-key-management (8.2.1)
Related
I have configured HTTPS on a Keycloak server by placing a certificate A.crt in a Java keystore and configuring that keystore in standalone.xml. HTTPS access has worked well from a given client so far. The certificate is signed by an intermediate CA B, which is signed by a root CA C.
I now encounter problems when accessing Keycloak from another client. It says: "unable to get local issuer certificate" or "certificate signed by unknown authority" (depending on the client software). I'm quite sure the root cause is that CA certificate B.crt is not known to this client. A strong indication is that I can access Keycloak from that client with curl --cacert B.crt https://keycloak....
Since I cannot predict which clients will have what CA certificates installed I would like to configure a bundle consisting of A.crt, B.crt, and C.crt as root certificate. If this were a server that directly took a PEM certificate I would use the bundle resulting from cat A.crt B.crt C.crt > bundle.crt, but because of its use of a Java keystore this is not an option with Keycloak.
So how can I store a server certificate bundle (it that's the right terminology) into a Java keystore so that Keycloak can make use of it in such a way that "all" clients can access the service?
UPDATE I've tried adding the intermediate and root certificates B and C to the keystore already used by Keycloak, but this did not solve the current issue:
keytool -import -alias b -file B.crt -keystore $KEYSTORE
keytool -import -alias c -file C.crt -keystore $KEYSTORE
You said having a keystore configured in your standalone.xml where A.crt was imported, but do you have a truststore? You could try adding B.crt in your truststore.
I am doing end to end performance testing of REST API using JMETER. The first step of any End to End Performance Testing is Authentication. My project supports only Smart Card Authentication, PKI Card. It does not have a facility to log in using Email Id and Password. If I open user interface, it asks me to enter Smart Card, then it navigates me to Organizations Entitlement Service and gets authenticated.
Go to JMETER -> Set HTTP Authorization. It does not work
Is there a way in JMETER to do this ?
So you need Client Certificate authentication.
In this case you need to use the following component:
CSV Data Set that will contains the alias in the keystore
Keystore Configuration that will read the keystore certificate and use the current alias extracted by CSV Data Set to find the certificate
Create a Keystore using client certificates and keytool utility
keytool -v -importkeystore -srckeystore client.p12 -srcstoretype PKCS12 -destkeystore ./loadtest.jks -deststoretype JKS -srcstorepass password -deststorepass password
Reference it using :
-Djavax.net.ssl.keyStore=path_to_keystore
-Djavax.net.ssl.keyStorePassword=password_of_keystore
By default setting up Solr on Https requires storing the certificate password as plain text in "bin\solr.in.cmd" (using windows to host solr)
And the certificate password is exposed in the portal.
How can I configure Solr with a Https certificate keeping the certificate password safe?
I want to use a private certifcate so the client trusts the certificate by default, rather than a self signed one.
I'm connecting via SolrNet from C#, currently without authentiation, but in the future can look at Basic Authentication which is supported in the provider which wraps SolrNet.
Seems like a basic thing which I would have thought should be supported? Can't find any article/documention on this.
Anyone solved this already?
Nearest I've found is:
Setting SOLR SSL properties
http://lucene.472066.n3.nabble.com/Prevent-the-SSL-Keystore-and-Truststore-password-from-showing-up-in-the-Solr-Admin-and-Linux-process-td4257422.html
Some suggestion of using jetty-https.xml and encrypt the configuration there.
Looking for a more complete answer.
update
I've come across the following Solr tickets:
https://issues.apache.org/jira/browse/SOLR-10307
https://issues.apache.org/jira/browse/SOLR-8897
Where support for loading the certificate passwords from environment variables has been added in Solr 7.0 and 6.7 (which hasn't been released yet).
I don't think using environment variables is much better, but some progress.
There is also a link to using Hadoop credential provider, but I'm not using Hadoop, so not applicable for me.
In the comments of the tickets, it mentions that someone tried the Jetty Password Utility, and Solr UI loaded over HTTPS. However the Collection API was erroring not being able to understand the password format.
So I'm still left without a way of configuring a certificate password for Solr, in a way I feel is secure.
For me the certificate password is not stored on the SOLR portal
see my setup
SSL
cd /path/to/solr/server/etc/
The following command will create a keystore file named solr-ssl.keystore.jks in the current directory
keytool -genkeypair -alias solr-ssl -keyalg RSA -keysize 2048 -keypass secret -storepass secret -validity 9999 -keystore solr-ssl.keystore.jks -ext SAN=DNS:localhost,IP:#ipsolr,IP:127.0.0.1 -dname "CN=localhost, OU=xxx, O=xxx, L=xxx, ST=xxx, C=xxx"
Convert the certificate and key to PEM format for use with Curl
keytool -importkeystore -srckeystore solr-ssl.keystore.jks -destkeystore solr-ssl.keystore.p12 -srcstoretype jks -deststoretype pkcs12
Next convert the PKCS12 format keystore into PEM format using the openssl
openssl pkcs12 -in solr-ssl.keystore.p12 -out solr-ssl.pem
After go to your $JAVA_HOME (into jre/lib/security)
curl --cacert /pah/to/solr/server/etc/solr-ssl.pem https://localhost:8983/solr/
Set Common SSL-Related System Properties
vi /etc/default/solr.in.sh
SOLR_SSL_KEY_STORE=etc/solr-ssl.keystore.jks
SOLR_SSL_KEY_STORE_PASSWORD=secret
SOLR_SSL_TRUST_STORE=etc/solr-ssl.keystore.jks
SOLR_SSL_TRUST_STORE_PASSWORD=secret
SOLR_SSL_NEED_CLIENT_AUTH=false
SOLR_SSL_WANT_CLIENT_AUTH=false
SOLR_SSL_KEY_STORE_TYPE=JKS
SOLR_SSL_TRUST_STORE_TYPE=JKS
Restart solr
service solr restart
For authentication
create security.json on SOLR_HOME (/var/solr/data/ for me)
Owner : root
See example of security.json to configure has you hope
After securing, add into solr.in.sh
SOLR_AUTH_TYPE="basic"
SOLR_AUTHENTICATION_OPTS="-Dbasicauth=solr:xxx"
it allows to have an answer on solr status service because with authentication it is not accessible
For me it's work and i don't see the certificate password on solr UI
Unable to go through realm discovery phase. While the samples code works good with IDP SSO circle. Facing issues when updated our securityContext.xml with our Company's Metadata.xml , imported pfx certificate and added to keystore.
Used below command to add to keystore :
keytool -importkeystore -srckeystore PFX_P12_FILE_NAME -srcstoretype pkcs12 -srcstorepass PFX_P12_FILE_PASS -srcalias SOURCE_ALIAS -destkeystore samlKeystore.jks -deststoretype jks -deststorepass nalle123 -destalias alias
PFB Exception Trace :
org.opensaml.common.SAMLRuntimeException: Can't obtain SP signing key
at org.springframework.security.saml.key.JKSKeyManager.getCredential(JKSKeyManager.java:193)
at org.springframework.security.saml.metadata.MetadataGenerator.getServerKeyInfo(MetadataGenerator.java:205)
at org.springframework.security.saml.metadata.MetadataGenerator.buildSPSSODescriptor(MetadataGenerator.java:329)
at org.springframework.security.saml.metadata.MetadataGenerator.generateMetadata(MetadataGenerator.java:189)
at org.springframework.security.saml.metadata.MetadataGeneratorFilter.processMetadataInitialization(MetadataGeneratorFilter.java:127)
at org.springframework.security.saml.metadata.MetadataGeneratorFilter.doFilter(MetadataGeneratorFilter.java:86)
and console messages as below :
No default metadata configured, generating with default values, please pre-configure metadata for production use
Unable to retrieve keystore entry for entityID (keystore alias): apollo
Check for invalid keystore entityID/alias entry password
Used the entityBaseURL as the end party url shared with client. Also tried with entity id that appears in metadata.xml.
Any help is truly appreciated.
While using self-signed Keystore using keytool command, key-pair password (specified for keytool option -keypass) and keystore file password must be same.
We can create self-signed Keystore using below command
keytool -genkeypair -alias springsaml -keypass <password> -keystore saml-keystore.jks
when receive message "Enter keystore password" on terminal, enter the same password, which is provided for keytool option "-keypass"
We've recently set up a Jenkins CI server on Windows. Now in order to use Active Directory authentication I'd like to require https (SSL/TLS) for access. Given this setup, what is the recommended way to do this?
Go to your %JENKINS_HOME% and modify the jenkins.xml. Where you see --httpPort=8080 change it to --httpPort=-1 --httpsPort=8080 you can make the ports anything you want of course, but in my testing (a while ago, it may have changed) if you don't keep --httpPort=<something> then Jenkins will always use 8080. So if you simply change --httpPort=8080 to --httpsPort=8080, port 8080 will still use http.
Also, if you want to use your own certificate, there are some instructions at the bottom of this page.
http://wiki.jenkins-ci.org/display/JENKINS/Starting+and+Accessing+Jenkins
Run:
keytool -genkey -keyalg RSA -keystore Jenkins.jks -alias [Name of website] -keysize 2048
Answer the questions remembering that First and last name is the website URL and should be lowercase. Example:
build.jenkins-ci.org
State or province cannot be abbreviated.
Run:
keytool -certreq -Keystore jenkins.jks -alias [Name of website] -file jenkins.csr -keysize 2048
Send Jenkins.csr to your cert provider and request a PKCS#7 cert which has a .p7b extension and starts with:
-----BEGIN PKCS #7 SIGNED DATA-----
Note: Trial certs are not normally available in .p7b format but you may be able to combine the .cer files using this tool which reported success but didn't work for me. (https://www.sslshopper.com/ssl-converter.html)
Run:
keytool -import -trustcacerts -file jenkins.p7b -keystore jenkins.jks -alias [Name of website]
Change the arguments node in Jenkins.xml to the following prespectivly.
<arguments>-Xrs -Xmx256m -Dhudson.lifecycle=hudson.lifecycle.WindowsServiceLifecycle -jar "%BASE%\jenkins.war" --httpPort=-1 --httpsPort=443 --httpsKeyStore="%BASE%\Cert\Jenkins.jks" --httpsKeyStorePassword=[Cert password from step 1]</arguments>
Troubleshooting:
If Jenkins doesn't start read the last lines from Jenkins.err.log.
If Jenkins didn't start because of an issue with Jenkins.xml, replace the – (weird Windows hyphen) characters with an actual - (ASCII hyphen).
If Jenkins starts but the cert still reads as bad, make sure the [Name of website] is the actual URL without the https: example: https://build.jenkins-ci.org would be build.jenkins-ci.org.
If that isn't the issue inspect the .jks file using KeyStore Explorer. The "Certificate Hierarchy" should show that each cert is nested in another; This is to illustrate the cert chain. If it shows the certs next to each other then it's not correct.
If it won't start on a specific port, 443 for example, then verify IIS or another app isn't currently using the port.
If you can see the site on the PC it's hosted on, but not another PC, then verify you aren't getting blocked by a firewall.
Step1: Create both public and private Certificate on your jenkin name (convert them into keysore file if its not)
Step2: Import the public certificate into your browser certificate mananger (import into all tabs)
Step3: Host your jenkin using JKS file which contain both public and private key.
For steps refer "Enable HTTPS in jenkins?"