I have created a self-signed certificate(public_certificate.crt), private key file(private_key.pem). and these are stored in keystore file keystore.jks.
I have configured the same keystore.jks file in the standalone.xml file of widlfly 10 in two section as:
Section 1:
<security-realm name="UndertowRealm">
<server-identities>
<ssl>
<keystore path="keystore.jks" relative-to="jboss.server.config.dir" keystore-password="changeit" />
</ssl>
</server-identities>
</security-realm>
Section 2:
<server name="default-server">
<http-listener name="default" socket-binding="http" redirect-socket="https" enable-http2="true"/>
<https-listener name="https" socket-binding="https" security-realm="UndertowRealm" enable http2="true"/>
<host name="default-host" alias="localhost">
<location name="/" handler="welcome-content"/>
<filter-ref name="server-header"/>
<filter-ref name="x-powered-by-header"/>
</host>
</server>
I have restarted the server, now when i am accessing the wildfly url(https://localhost:8443) it is coming as "Not Secure" in the browser url section of chrome.
I am having two question related to it:
With or Without configuring the standalone.xml file with our keystore, chrome is mentioning "Not Secure" in browser URL section. it might be because i am using self-signed certificate. but my question is, how will i know that my self-signed certificate is being used by Wildfly.
Is there any way to avoid "Not Secure" warning and it should be coming as "Lock" symbol in the browser for self-signed certificate.
Related
I configure a wildfly 20 and i have a problem with the ManagementRealm (security-realm) on ldap SSL.
With LDAP, it's OK, but as soon as i switch to ldaps the authentication no longer works.
The login window opens and whatever account I indicate (even a true or false login) I turn back to the "Connect to Management Interface" screen (practically blank).
And I have no errors in any log.
I tried a WildFly 19 and 20, on centos 8.
The trustore does exist, I added it in the startup variable (as well as its password)
Here is an excerpt from my standalone.xml file
<security-realms>
<security-realm name="ManagementRealm">
<authentication>
<local default-user="$local" skip-group-loading="true"/>
<ldap connection="ldap_connection" base-dn="OU=Utilisateurs,DC=org">
<advanced-filter filter="(&(sAMAccountName={0})(memberOf=CN=APP-ADMIN,OU=Utilisateurs,DC=org))"/>
</ldap>
<truststore path="truststore.jks" relative-to="jboss.server.config.dir" keystore-password="XXX" />
</authentication>
<authorization map-groups-to-roles="false">
<properties path="mgmt-groups.properties" relative-to="jboss.server.config.dir"/>
</authorization>
</security-realm>
<security-realm name="LdapSSLRealm">
<authentication>
<truststore path="truststore.jks" relative-to="jboss.server.config.dir" keystore-password="XXX" />
</authentication>
</security-realm>
</security-realms>
<outbound-connections>
<ldap name="ldap_connection" url="ldaps://serveurad:636" search-dn="user" search-credential="XXX"/>
</outbound-connections>
If anyone has an idea I would appreciate it.
A little late but I believe you have to also reference the security realm (containing the ref to the trust store) in your <outbound-connection />:
<outbound-connections>
<ldap name="ldap_connection" url="ldaps://serveurad:636" search-dn="user" search-credential="XXX" security-realm="LdapSSLRealm"/>
</outbound-connections>
I'm trying to configure websphere-liberty server to use default keystore and trustore for all outbound connections (actually REST calls) and for inbound use a custom key and trust stores. But it fails with SSLHandshakeException when try to make a call to external REST service. In logs I can see that it uses my custom truststore instead of default one.
Below is my server.xml
<?xml version="1.0" encoding="UTF-8"?>
<server description="Default server">
<featureManager>
<feature>appSecurity-2.0</feature>
<feature>transportSecurity-1.0</feature>
<feature>jaxrs-2.0</feature>
<feature>json-1.0</feature>
<feature>javaMail-1.5</feature>
<!--<feature>ssl-1.0</feature>-->
</featureManager>
<sslDefault sslRef="saasSSLConfig" outboundSSLRef="outboundSSLConfig" />
<ssl id="saasSSLConfig" keyStoreRef="saasKeyStore" trustStoreRef="saasTrustStore" clientAuthentication="true" sslProtocol="TLSv1" />
<keyStore id="saasKeyStore" location="/opt/ibm/wlp/output/defaultServer/resources/security/sbs_endpoint_keystore.jks" password="pwd" />
<keyStore id="saasTrustStore" location="/opt/ibm/wlp/output/defaultServer/resources/security/serverTruststore.jks" password="pwd" />
<ssl id="outboundSSLConfig" keyStoreRef="defaultKeyStore" trustStoreRef="defaultTrustStore" />
<basicRegistry id="basic" realm="BasicRealm">
<!-- <user name="yourUserName" password="" /> -->
</basicRegistry>
<httpEndpoint id="defaultHttpEndpoint" host="*" httpPort="9080" httpsPort="9443" />
<applicationManager autoExpand="true"/>
</server>
BTW if change saasSSLConfig to use defaultTrustStore instead of saasTrustStore then everything works fine.
Server version:
WebSphere Application Server 17.0.0.2 (1.0.17.cl170220170523-1818) on IBM J9 VM, version pxa6480sr4fp7-20170627_02 (SR4 FP7) (en_US)
Error:
[ERROR] CWPKI0022E: SSL HANDSHAKE FAILURE: A signer with SubjectDN CN=*.api.ibm.com, O=International Business Machines, L=Armonk, ST=New York, C=US was sent from the target host. The signer might need to be added to local trust store /opt/ibm/wlp/output/defaultServer/resources/security/serverTruststore.jks, located in SSL configuration alias saasSSLConfig. The extended error message from the SSL handshake exception is: PKIX path building failed: java.security.cert.CertPathBuilderException: PKIXCertPathBuilderImpl could not build a valid CertPath.;
SSLHandshakeException invoking https://dev.api.ibm.com/scx/test/sbs/customer/222222222: java.security.cert.CertificateException: PKIXCertPathBuilderImpl could not build a valid CertPath.
Liberty does not load cacerts automatically. You can create a keyStore element to point to it if desired. So in your case above you can create a configuration like this.
<ssl id="outboundSSLConfig" keyStoreRef="cacertKeyStore" />
<keyStore id="cacertKeyStore" location=<fill in path to your jdk cacerts file> password="changeit" />
I am assuming you do not need a key for this configuration so I simplified to just a keyStoreRef on outboundSSLConfig. It will use what is pointed to by keyStoreRef for both key and trust.
In your configuration I do not see keyStore elements for defaultKeyStore and defaultTrustStore. If they are missing that will cause outboundSSLConfig to be an invalid SSL configuration. Can you please add them and see if things work.
With WildFly 8.2.1, I am trying to make existing webservice (JAX-WS) use SSL, but I haven't seen any use of SSL in quickstarts and the information I was able to google is limited. So far I've added this to web.xml:
<security-constraint>
<display-name>Foo security</display-name>
<web-resource-collection>
<web-resource-name>FooService</web-resource-name>
<url-pattern>/foo/FooService</url-pattern>
<http-method>POST</http-method>
</web-resource-collection>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
and this is in my standalone.xml:
<subsystem xmlns="urn:jboss:domain:webservices:1.2">
<wsdl-host>${jboss.bind.address:127.0.0.1}</wsdl-host>
<endpoint-config name="Standard-Endpoint-Config"/>
<endpoint-config name="Recording-Endpoint-Config">
<pre-handler-chain name="recording-handlers" protocol-bindings="##SOAP11_HTTP ##SOAP11_HTTP_MTOM ##SOAP12_HTTP ##SOAP12_HTTP_MTOM">
<handler name="RecordingHandler" class="org.jboss.ws.common.invocation.RecordingServerHandler"/>
</pre-handler-chain>
</endpoint-config>
<client-config name="Standard-Client-Config"/>
</subsystem>
but apparently that's not enough; when I look into standalone/data/wsdl/foo.ear/foo.war/FooService/Bar.wsdl I see:
<service name="FooService">
<port binding="foowsb:FooBinding" name="FooBinding">
<soap:address location="http://localhost:8080/foo/FooService"/>
</port>
</service>
Note that in the EAR/WAR, the soap:address.location is filled just with a placeholder (I suppose that the value is ignored).
I've found some info about setting up security realm, and creating the self-signed certificate using keytool (which I did), but I completely miss how this should be linked together.
I've also tried to setup wsdl-uri-scheme=https, but this is supported only in later versions of CXF.
Seems that the soap:address.location value is not ignored when it's being replaced, since changing that from REPLACE_WITH_ACTUAL_URL to https://REPLACE_WITH_ACTUAL_URL did the trick - now the service got exposed on https://localhost:8443.
There is a couple of more steps I had to do in standalone.xml: in undertow, add https-listener:
<https-listener name="secure" socket-binding="https" security-realm="SslRealm"/>
define the SslRealm:
<security-realm name="SslRealm">
<server-identities>
<ssl>
<keystore path="foo.keystore" relative-to="jboss.server.config.dir" keystore-password="foo1234" alias="foo" key-password="foo1234"/>
</ssl>
</server-identities>
<authentication>
<truststore path="foo.truststore" relative-to="jboss.server.config.dir" keystore-password="foo1234"/>
</authentication>
</security-realm>
Note that I reuse the same keystore for server and clients here. And since my clients are ATM in the same WF node during development, I had to setup the client-side part there, too:
<system-properties>
<property name="javax.net.ssl.trustStore" value="${jboss.server.config.dir}/foo.keystore"/>
<property name="javax.net.ssl.trustStorePassword" value="foo1234"/>
<property name="org.jboss.security.ignoreHttpsHost" value="true"/>
</system-properties>
The last property should be replaced in WF 9+ with cxf.tls-client.disableCNCheck.
I've got test server and I would like to run many applications on that instance, but there's a problem with SSL certificates. If I'm using single certificate, everything is ok, but if when I add another, there is a problem.
This is my ssl realm configuration :
<security-realm name="ssl-realm">
<server-identities>
<ssl>
<keystore path="cert_one.jks" relative-to="jboss.server.config.dir" keystore-password="1234" key-password="1234"/>
<keystore path="cert_two.jks" relative-to="jboss.server.config.dir" keystore-password="1234" key-password="1234"/>
</ssl>
</server-identities>
</security-realm>
And this is my undertow server configuration:
<server name="default-server">
<http-listener name="default" socket-binding="http"/>
<https-listener name="defaultHttps" socket-binding="https" security-realm="ssl-realm" max-post-size="31457280"/>
<host name="one_app" alias="firstapp.com">
<filter-ref name="server-header"/>
<filter-ref name="x-powered-by-header"/>
</host>
<host name="two_app" alias="secondapp.com">
<filter-ref name="server-header"/>
<filter-ref name="x-powered-by-header"/>
</host>
</server>
As you can see I have two different certificate keystores, one for firstapp.com and another for secondapp.com.
But only certificate for secondapp.com is working. If I delete one of those keystores everything is OK. How to configure two or more certificates for different domains in Wildfly configuration?
I've been tearing my hear out trying to figure out why SSL works in one of my Azure projects but not in another.
When I navigate to my site, say https://foo.com, I can't even connect to the site. Browsers can't connect at all and curl says "couldn't connect to host". However, if I go to my cloudapp.net URL (e.g. https://foo.cloudapp.net), it can connect but browsers will complain and say my cert is for *.foo.com. Note: I am able to connect to http://foo.com without any trouble.
Here's my code with certain values obfuscated.
ServiceDefinition.csdef:
<?xml version="1.0" encoding="utf-8"?>
<ServiceDefinition name="MyApp" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition">
<WebRole name="www" vmsize="Small">
<Sites>
<Site name="Web">
<VirtualApplication name="r" physicalDirectory="../Foo/Bar" />
<Bindings>
<Binding name="Endpoint1" endpointName="Endpoint1" />
<Binding name="Endpoint2" endpointName="Endpoint2" />
</Bindings>
</Site>
</Sites>
<Endpoints>
<InputEndpoint name="Endpoint1" protocol="http" port="80" />
<InputEndpoint name="Endpoint2" protocol="https" port="443" certificate="STAR.foo.com" />
</Endpoints>
<Imports>
<Import moduleName="Diagnostics" />
</Imports>
<Certificates>
<Certificate name="STAR.foo.com" storeLocation="LocalMachine" storeName="My" />
</Certificates>
</WebRole>
</ServiceDefinition>
my cert is uploaded, the thumbprint matches (in this example it's also "1234567890")
ServiceConfiguration.csfg:
<?xml version="1.0" encoding="utf-8"?>
<ServiceConfiguration serviceName="myApp" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceConfiguration" osFamily="1" osVersion="*">
<Role name="www">
<Instances count="2" />
<ConfigurationSettings>
<Setting name="Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString" value="UseDevelopmentStorage=true" />
</ConfigurationSettings>
<Certificates>
<Certificate name="STAR.foo.com" thumbprint="1234567890" thumbprintAlgorithm="sha1" />
</Certificates>
</Role>
</ServiceConfiguration>
Azure Console:
I have verified that:
My cert is uploaded
It's SHA1
It's thumbprint matches what I've specified in ServiceConfiguration.cscfg (in this example it's "1234567890")
The certs for the Certificate Authorities are also present (for me it's "PositiveSSL CA" and "AddTrust External CA root")
For the Azure instance, it confirms there are 2 endpoints (port 80 and port 443)
Why would I not be able to connect at all via https://foo.com, but my https://foo.cloudapp.net will load (although triggering a browser warning)? This seem to indicate my configuration is correct but something else is off... ideas?
I think you may be looking in the wrong place for your problem!
How have you mapped foo.com to your site's address?
Note that Azure instances are given dynamic IP addresses - what address your site may be on NOW may not be what its on tomorrow. The recommendation for Azure is to add a "www" CNAME DNS entry in your domain records that points at "foo.cloudapp.net".
This way, when someone browses to www.foo.com, the DNS server will (invisibly) say "hey, actually, that site is as foo.cloudapp.net. The browser will then ask for the IP address of foo.cloudapp.net. This domain is managed by Microsoft who will return the current IP address for your site.
If you want foo.com to still get you to www.foo.com, you'll have to setup DNS redirection so that whenever someone types foo.com into their browser, they're redirected to www.foo.com. This will then cuase the browser to resolve foo.cloudapp.net and then the HTTP request will be sent to your site. Some domain hosters charge for this (typically a nominal fee), some offer it as a free service.
HTH.