We have a server (IBM i) which hosts a queue manager. We have a third party who connect to this using MQ client software (through a B2B interconnect). This is currently working with TLS but it was set up years ago and I'm trying to fully understand the moving parts because we want to change the certificate on the server.
As I understand things so far:
The server has a server certificate, issued by our company CA, along with our relevant CA certificates loaded in the server key store.
The client has a client certificate, issued by their company CA, along with their relevant CA certificates loaded in their key store.
The client and the server have each other's CA certificates loaded.
The server has a Server Connection Channel with a TLS CipherSpec defined, and a client certificate is required to connect.
What I do not understand is the link between what the client attempts to connect to (i.e. a connection string of some kind including a network address for the queue manager) and the server's certificate.
On the web, a server certificate's Common Name must match the name at which the web site was accessed. E.g. internally we can access a web server at https://server/somepage.html but if the certificate has server.company.com as the Common Name, then the browser will report it as insecure. Only using https://server.company.com/somepage.html is considered secure by the browser.
In the MQ Client-Server connection, does this relationship also need to be present? We currently have a server certificate with common name myserver. I want to change the server to use a different certificate with the common name myserver.company.com. Will this require the client to change their connection string or other configuration value?
The equivalent to the check that a web client does to ensure the server certificate's Common Name must match the name at which the web site, is for an MQ Client application to to set the value it expects in the SSLPEER attribute of it's CLNTCONN definition (or equivalent, say MQCD.SSLPeerNamePtr/Length in MQCONNX programmable interface).
Unlike web connections, there is no specific standard, so the MQ Client and MQ back-end queue managers would agree some standard to allow the MQ Client application to know it had connected to the correct queue manager.
There is also the reverse check, where the queue manager can set the SSLPEER value at the queue manager end of the connection and only allow MQ Client applications that provide a certificate with certain values in the Distinguish Name to connect to the queue manager.
Related
Can you use the same certificate for two MQ Qmgrs running in different servers? I know if you have the qmgrs in the same server you can use the same cert, but when you have two servers the CN(common name)of the certificate is the hostname, so it would be different for both and i am not sure if both of them can share the same cert.
The IBM MQ product only checks the DN value of the peer queue manager cert against the SSLPEER configured on the channel. MQ unlike browsers (and other software such as LDAP libraries) does zero validation of the DN (or SAN) against the hostname of the remote host.
There is no technical reason the same cert could not be used on two servers, this is very common when you have HA and DR configurations.
I would consider it best practice to have unique certs for each queue manager since these are used to prove identity.
Security implications for using the same certificate on two separate queue managers:
You have to copy the private key somehow between the two machines.
There are now two places an attacker could gain the single Certificate.
You can't rely on the SSLPEER feature on the client to ensure you connect to one specific QM but you could still ensure you have connected to a QM hosting that cert.
You can't rely on the SSLPEER feature on the connecting queue manager (SDR channel for example) to ensure you connect to one specific QM but you could still ensure you have connected to a QM hosting that cert.
No, client should reject connection as untrusted.
Client connects to particular server and CN in certificate, which server sends back to client, must be the same as is server name.
You can use SAN (Subject alternative name) to put there more FQDN or wildcard (*) in CN.
If client connects to MQserver1:1414, servers certficate must have MQserver1 in CN or in SAN of certificate
Based on this post, it's very unclear if a certificate is needed or not. The most important quote I got out of that post is this:
"I reached out to MS BizTalk support and they asked me not to use the
certificate and just use FTP over SSL without certificate. We also
changed the ftp firewall mode to passive and allocate storage to no."
Also consulted this post.
If FileZilla client can connect and send a file to a customer/vendor without a local certificate, then why would BizTalk need one in an FTP SendPort?
And secondly, if it is not needed, in what circumstances would you use it on an FTP SendPort.
It's my understanding that the certificate is some certificate related to the BizTalk host account's personal store on the BizTalk machine, and not the thumbprint of the customer/vendor we are communicating with.
For BT2013 this is MSDN's mysterious definition:
Specify the SHA1 hash of the client certificate that must be used in
the Secure Sockets Layer (SSL) negotiation.
Based on this hash, the client certificate is picked up from the
personal store of the user account under which the BizTalk host
instance is running.
This statement gives no guidance as to when it is needed or desired.
This is the other good blog on the subject, but also implied cert is needed, in contradiction to Microsoft support in early link.
You need to use the client certificate, when the FTPS server requires authentication with the client certificate. And you do not use it, when the server does not require that (what is a way more common).
FileZilla does not support the client certificates at all. If you are able to connect with FileZilla, your FTPS server does not require authentication with the client certificate. So you just leave the respective field in BizTalk blank.
New SSL certificates cannot contain internal server names, starting sometime in 2015. Right now I have a SAN certificate (certificate with a few names on it). Two are external mail.domain.com and autodiscover.domain.com. One is internal server.domain.internal. I have my Exchange server setup to use external domain names for all connections. Everything works, including Outlook Anywhere.
However when connected a new client (Outlook account) the server name that gets filled into the setup is the internal server name. Also when running an AutoConfiguration test in Outlook the internal server name is filled in for RPC server name.
When getting a new certificate I cannot request a certificate that contains an internal name. So I would like to get this fixed as I believe it will cause issues with the certificate not containing the internal name.
I've found this article about Client Access Server Arrays (http://exchangeserverpro.com/exchange-server-2010-cas-array/). Am I on the right page or am I not thinking correctly here.
Following the steps in the article mentioned above did clear my issues. The RPC server name is now the same as the external name. This will allow us to comply with the new SSL certificate requirements and our clients will not experience any certificate errors.
I am trying to figure out how we would configure / setup the authentication, Queues, and Queue managers for connecting an MQ Client that is on a server / domain completely separate from the MQ Server it will be forwarding messages to.
I would assume that in a normally organizational environment you could just use Active Directory (if hosted on windows servers) for the authentication / AD lookup. However, in this scenario because they are different orgs you couldn't do that?
Can you simply apply SSL certs to both client / server and use that as your authentication? If so is that just applied to the Channel used in the connections?
Not sure how to proceed forward with this.
Any suggestions would be greatly appreciated.
Thanks,
S
Take a look at the Hardening WebSphere MQ presentation for v7.0 and earlier. The thing to remember is that WMQ does not authenticate anything. It authorizes based on OS identities and groups but there is no password checking being done.
For situations where QMgrs and clients live on Windows networks, the connection uses the SID and so it appears that some useful authentication was performed. BUT if a connection from a non-Windows platform is attempted, the Windows QMgr uses the string representation of the ID. So for example, if someone has a Linux VM on their desktop they can easily create a user ID called MUSR_MQADMIN and the Windows QMgr will accept the connection. There is a setting that causes the Windows QMgr to only accept connections with SIDS that it can resolve but even there its just a matter of knowing what the SID values are to spoof them on a connection.
The lesson here is that any QMgr, even one on Windows, must be configured to authenticate remote connections. With WMQ v7.1 and later, the QMgr has functionality to map X.509 certificate DNs to user IDs, or to perform IP filtering. Prior to v7.1 these functions required an exit such as BlockIP2. Capitalware sells MQAUSX which has the functions of BlockIP2, plus will perform ID and password authentication and is supported.
The first recommendation is to use a v7.1 QMgr so that you get the CHLAUTH rules for mapping and filtering. Even if you don't use certificates v7.1 limits administrative connections so it is harder for an attacker to gain full admin rights. Then if you need password validation, use SSL channels (to encrypt the password and prevent simply replay attacks) in combination with an exit that you can write yourself or purchase.
Just be aware that allowing a connection from outside your domain doesn't present any new challenges. The pre-v7.1 Windows QMgr that does not have MCAUSER set in the channel definition or by an exit allows remote administrative access, even from connections originating in the local Windows domain. There was always a need to harden that QMgr, even though honest users will have received authorization errors if the administrator did not set up auths for them.
Summary:
For clients originating outside your administrative domain, I'd recommend mutually authenticated TLS/SSL channels. The same page I linked to above also contains the WMQ Security Lab guide and scripts which show how to script the creation and exchange of WMQ certs and configure WMQ Explorer with them.
Whatever else you do, the MCAUSER on any legitimate channel must be set either in the configuration or by an exit. If the client is allowed to specify the ID, there is nothing to prevent it from specifying an administrative ID. For channels that are NOT being used such as SYSTEM.DEF.* and SYSTEM.AUTO.*, set the MCAUSER to a value that cannot be a local ID such as no!body or on v7.1 and later *NOACCESS.
I am planning to implement a small standalone program that will make a https request to a server. Does that require a valid ssl certificate in the client? How does the SSL handshake work in that case? Are there any security issues in the client not have an SSL certificate?
Apart from encrypting the network traffic, HTTPS is normally used to authenticate the server. That is, to give clients reassuring information about who owns the server, etc. For that to work, the client needs to inspect the trust chain in the certificate published by the server. For that to happen automatically, the client machine should have a certificate installed that describes a Certification Authority that issued the server's certificate. Normally such certificates are found on your machine in a store called "Trusted Root Certification Authorities" and most OS come with a set of common CAs already installed.
In addition, many web servers offer a feature where the client can authenticate itself to the server by supplying a client certificate. The web server is able to inspect the certificate coming from the client and map it onto a set of permissions on the server. This "client authentication" is not necessary for a working HTTPS session however, it's just an option.
In short, you don't actually need any certificate on the client, but you will probably want to have a root CA certificate in order to validate the server's identity. If you don't have that certificate it will be impossible for you to trust the server (unless you have another good reason to do so), but you might choose to exchange data with it anyway.
If you wish to learn more about the HTTPS handshake and what is negotiated, i fully recommend you look at this excellent write up at moserware
http://www.moserware.com/2009/06/first-few-milliseconds-of-https.html
A client certificate is required only if the server requires one. A client certificate allows the server to authenticate the client, but this is only useful if the server has a list of all authorized clients. That's generally not the case with a web server, so it's quite rare for them to require client certificates.
When present, the client-side certificate does not affect establishment of the secure channel. (Only the server's certificate is required for that and adding a client certificate into the mix doesn't change the process.) Once a secure channel is established, the server will use the client's certificate the authenticate the client (generally by comparing the client's public key or name with a list of authorized clients).
You dont need a certificate to make a HTTPS connection, but you do need to if you want to know with whom you are communicating.