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
Related
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.
for my new task I have to use SCOM to monitoring non-domain server/computer. My company told me to do it with only 1 server management that contains others SCOM features. So I have a server Windows 2016 with SCOM with a local domain, and I have to connect the others devices. It seems easy, but I have a problem with certificates: when I try to certificates my server & computers, and I'll import the certificate with MOMCertImport, in Event Viewer I see the event id 21007, that tell me "The OpsMgr Connector cannot create a mutually authenticated connection to 'PC-NAME' because it is not in a trusted domain." So I have the certificates installed but I can't anyway connect Agent to SCOM, What will I do? I search anywhere for this problem, but any solution not work with me!
There are few things you need to look at.
The certificate: must have both client auth and server auth purposes.
Authentication is MUTUAL, i.e. you agent confirms its identity to a gateway, or to a management server, AND the gateway or management server confirms its identity to the agent.
Certificates must be issued to EXACT conputer FQDN. If you rename, or join domain, or change DNS suffix => this will invalidate certificate, because FQDN changes.
Install and bind certificates at both participating servers (i.e. agent and (MS or GW)). This is because #2.
Obviously, you need individual certificates for each server, because of #3.
Ensure, that both servers can maintain trust chanin to own certificate and to other party's one. Ideally, if you have a single root/issuing CA, which used to issue both certificates. In this case, just install root/issuing CA certs in appropriate storages in local computer account. If using self-signed, you need to install them as trusted at other party.
For this situation I'm using WSO2 Enterprise Integrator 6.4.0
I currently find myself in the situation where I have 1 endpoint (SOAP) controlled by government (which I need to use) and multiple of our end customers need to connect to. In order for this to work, all the end customers need to address the same endpoint in the same fashion but using their own client certificate.
So customer 1 has certificate 1 and customer 2 needs certificate 2, etc.
AS far I as could tell, from documentation and trying, one endpoint can only ever use a single certificate in its connection. Since the amount of customers might change on a daily basis I would to have a single common solution to this problem.
Currently to circumvent this problem I'm creating a design in which I use endpoint per customer and a reverse proxy to connect to the final endpoint. This is however not ideal since I would still need to create 1 endpoint per customer, which might turn out to be pretty intensive.
I'm open to any suggestions.
You are right that you cannot get the ESB to present a different certificate based on the client that is trying to connect. If you really want to go down that route putting a reverse proxy (like nginx) in front of the ESB and using that to handle the SSL could work, but I wouldn't really recommend doing that.
If you are wanting mutual SSL (link, link) then you need to add the certificates of the clients that will be connecting to your endpoint to your client trust store. The default truststore is located at <wso2EI_home>/repository/resources/security/client-truststore.jks. To import a cert keytool -import -trustcacerts -file <cert-file-name> -alias <choose-a-useful-name> -keystore client-truststore.jks The default password is wso2carbon.
Doing this does require you to maintain the certificates, when a client cert changes because it expired you need to import the new one. They won't be able to connect until you do.
Another option could be to disable mutual SSL and have you endpoint open for anyone (that you allow through your firewall) to be able to connect. You won't have to maintain a list of client certificates. The traffic will still be encrypted, you will just lose the tight control over who can connect.
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.