I'm trying to configure Artemis to allow connections using the CERT provided by the java client using the DN as the username. I have read almost all the documents and things I could find asking 'the google', but alas, I find myself at a frustrating stand-still.
I have the acceptor configured:
<acceptor name="netty=ssl-acceptor">tcp://0.0.0.0:5500?sslEnabled=true;keyStorePath=xxxx;keyStorePassword=xxxx</acceptor>
And on client side I am passing the CERT (or at least I think I am). Here's the URL I'm using:
tcp://mynode:5500?sslEnabled=true;useDefaultSslContext=true
I have also used this URL:
tcp://mynode:5500?sslEnabled=true;keyStorePath=xxxx;keyStorePassword=xxxx
Without posting code (different network), can anyone provide any well-known issues or hints that might be causing the server to say:
Unable to validate user from /x.xxx.xxx.xxx:xxxx. Username: null; SSL certificate subject DN: unavailable
The message you're seeing indicates that you're not passing any credentials when you connect (either username/password or SSL certificate). The reason you're not passing any credentials is because your acceptor configuration is incorrect since you're not telling clients to actually provide a certificate. You need to set needClientAuth=true, e.g.:
<acceptor name="netty=ssl-acceptor">tcp://0.0.0.0:5500?sslEnabled=true;needClientAuth=true;keyStorePath=xxxx;keyStorePassword=xxxx</acceptor>
On the client, you should only use useDefaultSslContext=true if you're explicitly configuring the default SSL context (which is rare). You most likely should be using your second options where you configure keyStorePath and keyStorePassword.
Also, keep in mind that you'll need to either use certificates signed by a trusted authority or you'll need to create and configure trust stores on your client and broker and add the proper certificates to them.
You need to set the Artemis user Preferences. Click profile account and select Preferences. If it empty, please fill out the default user first.
You need to add an extra acceptor configuration to disable the SSL. Open up etc/broker.xml and add following configuration.
<acceptor name="netty-ssl-acceptor">tcp://0.0.0.0:61617?sslEnabled=false</acceptor>
Now it should work
Related
How to change security policy in milo example server? I've tried to connect to milo's opc server with UaExpert, and set the security policy. No matter what security policy I choose, the result is the same error:
ERROR o.e.m.o.s.s.t.u.UascServerAsymmetricHandler - [remote=/127.0.0.1:33762] Exception caught; sent ErrorMessage{error=StatusCode{name=Bad_SecurityChecksFailed, value=0x80130000, quality=bad}, reason=certificate path validation failed}
io.netty.handler.codec.DecoderException: UaException: status=Bad_SecurityChecksFailed, message=certificate path validation failed
How can I configure it correctly?
Second question: The example server seems quite complicated. What is the simplest way to create a server and connect to it? Is there a minimal example for that?
Welcome to stackoverflow
I do not know the Milo server and I have not almost used UAExpert but:
The client must trust the server certificate and the server must do the same with the client's certificate and of course both sides must have their certificate, sometimes the client and the server automatically create one if it doesn't exist but sometimes it should be created previously by external ways.
Help about UAExpert http://documentation.unified-automation.com/uaexpert/1.4.3/html/first_steps.html
If you don't want to deal with certificates then choose then endpoint with SecurityPolicy None when connecting:
Otherwise, note the security directory the example server logs on startup. Something like:
INFO o.e.m.examples.server.ExampleServer - security temp dir: /var/folders/1v/2pxlxd_x4bsdxz25_fv7r0940000gn/T/security
Navigate to the security directory and you'll find the UaExpert client certificate in the pki/rejected folder. You can move it to pki/trusted/certs and then connect with security from UaExpert.
I can't work out a definitive answer on this, but from searching I find two links which seem to indicate to me that a server (in this case it's MS Exchange as per the links) can have different certificates in place for https than for secure smtp/TLS.
http://technet.microsoft.com/en-GB/library/bb851505(v=exchg.80).aspx
https://www.sslshopper.com/article-how-to-use-ssl-certificates-with-exchange-2007.html
I have an issue which no-one has been able to help with here and this question is a follow on, in that I am coming to the suspicion that my first problem is that my machine trusts the https certificate, but not the one being used for smtp/TLS. But what I'm asking now, is that even possible?
Going through the diagnostic steps here shows me that the certificates in use when I access my mail server's web interface through https are fully trusted. However when I look at the debug of my c# process it is stating a completely different certificate issued by one of our servers to it's self (the server on which exchange is installed).
So... any one know if it's possible that I am thinking along the right lines... is it possible that when I do an https connection I get one certificate and when I use the .net SMTP client I get a completely different certificate (from exactly the same address, but I assume a different port)?
Is it possible that when I do an https connection I get one certificate and when I use the .net SMTP client I get a completely different certificate (from exactly the same address, but I assume a different port)?
Yes, you can have a different certificate for each listening socket on the machine, that is SMTP and HTTPS can use different certificates. On a machine with multiple hostnames you could even have multiple different certificates on a single socket, which get distinguished by the hostname (using SNI).
Currently I am using Net::LDAP::Server to setup my server but it is not secure enough.
Is there any module or method so that I can setup a LDAP server over TLS or other secure connection?
I just found many information about how to connect to a secure ldap server, but cant found how to setup a secure ldap server.
Can anyone give some advices?
How does an LDAPS connection work
LDAPS is an unofficial protocol. It is to LDAP what HTTPS is to HTTP, namely the exact same protocol (but in this case LDAPv2 or LDAPv3) running over a secured SSL ("Secure Socket Layer") connection to port 636 (by default).
Not all servers will be configured to listen for LDAPS connections, but if they do, it will commonly be on a different port from the normal plain text LDAP port.
Using LDAPS can potentially solve the vulnerabilities described above, but you should be aware that simply "using" SSL is not a magic bullet that automatically makes your system "secure".
First of all, LDAPS can solve the problem of verifying that you are connected to the correct server. When the client and server connect, they perform a special SSL 'handshake', part of which involves the server and client exchanging cryptographic keys, which are described using X.509 certificates. If the client wishes to confirm that it is connected to the correct server, all it needs to do is verify the server's certificate which is sent in the handshake. This is done in two ways:
check that the certificate is signed (trusted) by someone that you trust, and that the certificate hasn't been revoked. For instance, the server's certificate may have been signed by Verisign (www.verisign.com), and you decide that you want to trust Verisign to sign legitimate certificates.
check that the least-significant cn RDN in the server's certificate's DN is the fully-qualified hostname of the hostname that you connected to when creating the LDAPS object. For example if the server is , then the RDN to check is cn=ldap.example.com.
You can do this by using the cafile and capath options when creating a Net::LDAPS object, and by setting the verify option to 'require'.
To prevent hackers 'sniffing' passwords and other information on your connection, you also have to make sure the encryption algorithm used by the SSL connection is good enough. This is also something that gets decided by the SSL handshake - if the client and server cannot agree on an acceptable algorithm the connection is not made.
Net::LDAPS will by default use all the algorithms built into your copy of OpenSSL, except for ones considered to use "low" strength encryption, and those using export strength encryption. You can override this when you create the Net::LDAPS object using the 'ciphers' option.
Once you've made the secure connection, you should also check that the encryption algorithm that is actually being used is one that you find acceptable. Broken servers have been observed in the field which 'fail over' and give you an unencrypted connection, so you ought to check for that.
How does LDAP and TLS work
SSL is a good solution to many network security problems, but it is not a standard. The IETF corrected some defects in the SSL mechanism and published a standard called RFC 2246 which describes TLS ("Transport Layer Security"), which is simply a cleaned up and standardized version of SSL.
You can only use TLS with an LDAPv3 server. That is because the standard (RFC 2830) for LDAP and TLS requires that the normal LDAP connection (ie., on port 389) can be switched on demand from plain text into a TLS connection. The switching mechanism uses a special extended LDAP operation, and since these are not legal in LDAPv2, you can only switch to TLS on an LDAPv3 connection.
So the way you use TLS with LDAPv3 is that you create your normal LDAPv3 connection using Net::LDAP::new(), and then you perform the switch using Net::LDAP::start_tls(). The start_tls() method takes pretty much the same arguments as Net::LDAPS::new(), so check above for details.
Well, perhaps LDAPS is not an RFC but to say it is not a standard or secure is certainly a stretch.
LDAPS is supported by ALL LDAP Server Vendors.
LDAPS is at least as secure as HTTPS.
As with ALL SSL (or TLS) the security weak points are how the certificates are handled.
Certainly LDAPS is more supported by LDAP server vendors and clients than is TLS. Active Directory as one example, does not support TLS. Querying the rootDSE for the supportedExtention 1.3.6.1.4.1.1466.20037 will (should) show if TLS is supported on any particular LDAP server.
We have some examples at:
http://ldapwiki.willeke.com/wiki/Perl%20LDAP%20Samples.
Is it possible that weblogic uses a custom ssl socket implementation? I'm running into a problem with the JavaMail. Trying to use a smtp ssl connection fails even though I've setup a custom truststore with the mailserver ca. However if I set the javax.net.ssl.trustStore property to use a truststore with the mailserver ca everything works.
This makes me think that weblogic uses their custom sockets or custom config for sockets. While JavaMail relies on the standard mechanisms and will not take into account what's in the weblogic custom truststore.
Any ideas?
(posted as an answer - thanks!)
WebLogic Server doesn't use custom socket implementation that I'm aware of. I've integrated it in the past with a number of client applications or other servers. That being said, SSL is gloriously frustrating to get working right. Can you post the exceptions/errors you're getting in your logs when WebLogic Server tries to make the connection? If you're not seeing anything in the logs, depending on the version of WebLogic Server you're using, there are a number of debug flags you can enable to get more information.
By default WebLogic uses the Certicom SSL implementation. My experience of this library has been nothing but grief. You haven't provided any details of the error but I would enable the Sun implementation to see if that helps. In the "Advanced" tab in the SSL-configuration there is a checkbox called "Use JSSE SSL" which will do it.
Or you can do it with system properties like so:
http://weblogic-wonders.com/weblogic/2010/11/09/enforce-weblogic-to-use-sun-ssl-implementation-rather-than-certicom/
Does anyone have an experience or just thoughts about securing MQ TCP
communication channels using stunnel?
I am integration with third party S.W which has MQ support built in but it can not support SSL. So to have some kind of security over the TCP we would like to use stunnel. Does any one have any thoughts how to implement and any best practices
I haven't used stunnel so I'll leave that part of the answer to another responder. With regard to WMQ, keep in mind that this will provide you with data privacy and data integrity over the stunnel link but will not give you channel-level services such as WMQ authentication. True, you will have some level of authentication on the stunnel connection itself, but anyone with a TCP route to the QMgr that does not arrive via stunnel will also be able to start that channel.
Your requirement for security obviously includes data privacy. If it also includes authentication and authorization, you might need to use something like BlockIP2 (from http://mrmq.dk )to filter incoming connections on that channel by IP address to insure they arrive over the stunnel link. Of course, there is nothing to prevent someone at the remote end from specifying any channel name to connect to so if you secure one channel, you need to secure them all - i.e. make sure that SYSTEM.DEF.* and SYSTEM.AUTO.* channels are disabled or that they use SSL and/or an exit to authenticate the inbound connection.
Finally, be aware that if WMQ is configured to accept the ID presented by the client then the connection has full administrative access and that includes remote code execution. To prevent this you must configure all inbound channels (RCVR, RQSTR, CLUSRCVR and SVRCONN) that are not administrative with a low-privileged ID in the channel's MCAUSER. For any channels that are intended for administrators, authenticate these with SSL. (Hopefully your 3rd party SW is an application and not an administrative tool! Any WMQ admin tool must support SSL or else don't use it!)
So by all means use stunnel to secure this link, just be sure to secure the rest of the QMgr or else anyone who can legitimately connect (or even anonymous remote users if you leave MCAUSER blank and aren't using SSL and/or exits) will just bypass the security or disable it.
There's a copy of the IMPACT presentation Hardening WMQ Security at https://t-rob.net/links/ which explains all this in more detail.
Rob - I agree with you. For that only we have MQIPT. Which is much better. For STunnel for MQ i have sloved the problem.
Keys -U need a .pem key (From Key manager you can create .p12 and use open ssl to covert to .PEM).
Client Side: Download and install stunnel have followoling entries in the config file
cert = XXX.pem
client = yes
[MQ]
accept = 1415
connect = DestinationIP:1415
Server Side:
cert = xxx.pem
client = no
[MQ]
accept = 1415
connect = MQIP:1415
Once you do this all you have do is just call the amquputc with the Queue name.