When connecting to our load-balanced Service Bus instance via AMQP, we cannot send messages to a queue or topic.
We have a Windows Server 2012 R2, running in a VM on Hyper-V. The server is part of a NLB cluster (which currently only contains this single host). On the server, we installed Service Bus for Windows Server 1.1 and configured the farm, host and namespace using the following PowerShell script:
$machineName = 'server'
$domainName = 'sb.department.company.com' # this DNS name is linked to the virtual IP address of the NLB cluster
$namespace = 'namespace'
New-SBFarm -SBFarmDBConnectionString "Data Source=$machineName;Integrated Security=True" -FarmDns $domainName -EncryptionCertificateThumbprint $certThumbprint -FarmCertificateThumbprint $certThumbprint -RunAsAccount $accountName
Add-SBHost -SBFarmDBConnectionString "Data Source=$machineName;Integrated Security=True" -EnableFirewallRules $true -RunAsPassword $securePassword -ExternalBrokerUrl "sb://$domainName"
New-SBNamespace -Name $namespace -AddressingScheme 'Path' -ManageUsers $userGroupName
First we tried generating certificates using makecert, but these certificates did not have the Subject Alternative Name property. As a solution to this issue, we used OpenSSL to generate our certificates. Here's the chain of certificates we use:
Company CA
Signature algorithm: sha256RSA
Public key: RSA (2048 bits)
Subject: O = Company, CN = Company CA
Basic Constraints: Subject Type = CA, Path Length Constraint = None
Key Usage: Certificate Signing, Off-line CRL Signing, CRL Signing
Company Department CA
Signature algorithm: sha256RSA
Public key: RSA (2048 bits)
Issuer: Company CA
Subject: O = Company, CN = Company CA
Basic Constraints: Subject Type = CA, Path Length Constraint = None
Key Usage: Certificate Signing, Off-line CRL Signing, CRL Signing
sb.department.company.com
Signature algorithm: sha256RSA
Public key: RSA (2048 bits)
Issuer: Company Department CA
Subject: O = Company, CN = sb.department.company.com
Basic Constraints: Subject Type = End Entity, Path Length Constraint = None
Key Usage: Digital Signature, Non-Repudiation, Key Encipherment, Data Encipherment
Enhanced Key Usage: Server Authentication
Subject Alternative Name: DNS Name = sb.department.company.com
These 3 certificates are installed in the certificate store of the local machine (not of the current user):
The root certificate (Company CA) is installed in Trusted Root Certification Authorities.
The intermediate certificate (Company Department CA) is installed in Intermediate Certification Authorities.
The server certificate (sb.department.company.com) is installed in Trusted People.
When we use a web browser to connect to https:// sb.department.company.com:9355/namespace, we can see that the certificates are correct and trusted.
When we use the .NET library to connect to the Service Bus instance, we can do everything (get list of queues/topics, create queues/topics, send messages to a queue, ...).
When we connect using AMQP in our C++ application (on Linux), we cannot send messages to a queue.
This can easily be demonstrated via Service Bus Explorer: if we set transport type to AMQP, we get this erratic behavior. We can get the list of queues and topics, but when trying to send messages we get the following error message: Exception: The remote certificate is invalid according to the validation procedure.. Method b__be.
How can we solve this?
After consulting Microsoft support we were able to resolve the issue. Here's a short description of the problem.
The client connects to the Service Bus Gateway via the NLB domain name (the certificate validation succeeds, because it contains the NLB domain name).
When trying to send a message, the Service Bus Gateway redirects the client to a Service Bus Message Broker on one of the servers.
The client connects to the server using the domain name or machine name of the server.
Certificate validation fails, because the certificate does not contain the domain name or machine name of the server.
The solution is to include the domain names (or machine names, if not in a domain) of all the servers of the farm in the Subject Alternative Names property of the 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.
I have WSO2 API manager deployed in AWS EC2 instance.
I have purchased a SSL certificate via sslforfree.com. I tried to import it via keytool command. But its not working and throwing error. It gives me
KrbException: Cannot locate default realm
How can I associate this certificate with the API Manager? I don't have a domain name for WSO2 and I access it via IP address.
Is it possible for have CA signed certificate in this case?
In case if I want a domain name for this EC2, how can I have one?
You can import the certificate inside Carbon. Log into <your_server>:9443/carbon as admin. After that go on Main -> Manage -> Keystores -> List
If you're still using the default settings you'll have the wso2carbon.jks entry here. Click on Import cert, chose your cert file and click on Import. Your certificate should be working after this.
there are several topics in this question:
I tried to import it via keytool command.But its not working and
throwing error.It gives me KrbException: Cannot locate default realm
The keytool gives you this exception? It would be useful to provide the keytool command you've used. There's not reason for that exception.
please not that the certificate CN must be the same as the fqdn (domain name) of the server (how your browser access it).
How can I associate this certificate with the API Manager?
There are two options.
Import the keypair (private key and certificate chain) into a keystore and configure the APIM to use the keystore (in the repository/conf/tomcat/catalina-server.xml)
Have a reverse proxy server (Apache HTTP, NGinx), and configure the SSL on that proxy server. This is my favorite approach .
See: https://docs.wso2.com/display/AM210/Adding+a+Reverse+Proxy+Server
Then you have control over who/where can access the carbon console, store and publisher.
I don't have a domain name for WSO2 and I access it via IP address. Is
it possible for have CA signed certificate in this case?
Certificate authorities don't provide IP based certificate, as they can validate ownership/control of a domain name, but not of the IP address.
You can create (and made trusted) your own CA and certificate (good for PoC, DEV environment, ..) but in long run you'll need a trusted certificate on a hostname.
In case if i want a domain name for this EC2 , how can i have one ?
You can always buy one :D For start - when having EC2 instance with a dynamic IP address, you may use some dynamic dns service (e.g. https://ydns.io/ , just search for more if you wish)
Excuse me if this question is really naive, but I searched as much as I could without being able to find relevant answers.
I spent the last three days trying to understand how https works.
All I knew before these days is how symmetric and asymmetric cryptography works.
It was about time for me to understand how these two are applied on ssl-https and achieve the so called data encryption and server identity verification.
Everything is clear regarding the data encryption and the prevention of man-in-the-middle attacks
It seems though that I don't completely understand how server identity verification works, so your help will be highly appreciated.
My understanding so far is the following:
When a client connects to a server via https, the server sends a signed by a CA certificate.
This server certificate is a text file containing information regarding the server(name, owner email, public key etc..), plus a digital signature.
This signature is a hash of the content of the server information, encrypted by the CA private key.
The client checks the validity of the signature by producing again -on his own- the hash of server info and decrypting the signature using the CA's public key. If the decrypted signature value is the same with the produced hash, the signature and the certificate subsequently are valid.
Note here that the public-private encryption scheme has a dual nature. A message can be encrypted by the public key and decrypted by the private key. The same message can be encrypted with the private key and decrypted by the public key as well.
What we need to keep in our minds here is that the certificate is a static and non change-able file. Any change on the file will result in a signature mismatch.
I will describe now a way to fool https:
Lets say theres an ebanking site with URL = https://wwww.TheBank.com/ebanking (public IP = 195.134.0.1)
I connect to this URL and my browser gets the server certificate. (theBank.cer)
On the same time I'm the owner of an internet cafe. My internet cafe has its own router, DNS and DCHP servers which I have the knowledge to control. It has a web server as well.
I configure the web server to own ip 195.134.0.1, same as the bank's
I create a route to my router that sends connection requests for 195.134.0.1 to my web server
I configure my DNS to point the above bank URL to 195.134.0.1(my web server)
I place a fraudulent bank site on my web server. For any connections on this site, I instruct the web server to send to the client the certificate I downloaded before.( theBank.cer)
A user comes to my cafe, gets connected to my network and attempts to connect to this bank. My server sends to him the certificate of the bank. His browser will confirm the validity of the certificate, since its indeed the valid one and allow a connection to my fake web site since its URL, IP and hostname are the same with the real one.
So my fraud is successful.
Of corse, this security hole is too obvious to be true. Meaning I haven't understood something in this server identity verification procedure. Can someone please explain to me what I am missing here?
A user comes to my cafe, gets connected to my network and attempts to connect to this bank. My server sends to him the certificate of the bank. His browser will confirm the validity of the certificate, since its indeed the valid one and allow a connection to my fake web site since its URL, IP and hostname are the same with the real one.
Once his browser has confirmed the validity, it knows the bank's real public key, since that's in the certificate. Since your server can't sign anything with the private key corresponding to that public key, nor can you decrypt anything encrypted with that public key, you can't impersonate the bank at all. All you can do is convince the user of the bank's real identity, which you can't impersonate.
I think the key thing you're missing is that the primary purpose of a certificate is for a trusted authority to bind a real-world identity to a public key, such that only the owner of that real world identity knows the corresponding private key.
theBank.cer is a public key.
You cannot use it to decrypt or sign anything.
This signature is a hash of the content of the server information,
encrypted by the CA private key.
The client checks the validity of the signature by producing again -on
his own- the hash of server info and decrypting the signature using
the CA's public key. If the decrypted signature value is the same with
the produced hash, the signature and the certificate subsequently are
valid.
This is more or less what happens with RSA, but not with DSA, which is signature only (no encryption).
In general, you shouldn't talk about "encrypting" with a private key. It doesn't make any sense, since anyone would be able to decrypt with the public key (since it's public). Encryption is about hiding information.
What you can do with a private key is sign and decrypt/decipher. What you can do with a public key is encrypt and verify a signature.
If you mix up when encryption is required and when signatures are required (despite the fact the algorithm are very similar with RSA), you can end up designing systems that don't provide any security.
More generally, the purpose of a public key certificate (X.509 certificate, or even PGP certificate) is to bind an identity (e.g. the server host name) to a public key. (See this question on Security.SE.)
The data my web server will receive will be encrypted by the public
key of the bank
Note that the SSL/TLS traffic is not encrypted using the certificate's private key, but shared keys negotiated during the SSL/TLS handshake.
During the SSL/TLS handshake, that public key is used either to encrypt the pre-master secret or to sign other parameters (depending on the cipher suite), which end up proving to the client that it's communicating with a server that has the private key for this public key.
Since the certificate also binds the server name to the public key, the client then knows it's communicating with the right server.
This is why it's important to verify that (a) the certificate is trusted and (b) it's issued to the server name the client wanted to connect to.
According to MSDN documentation, to send more than 500 push notifications per day, your service needs a certificate to establish an SSL tunnel to the WNS.
I see here http://msdn.microsoft.com/library/windows/apps/ff941099(v=vs.105).aspx how to upload the certificate, but how do I get the certificate? Do I need to install the certificate the my web server hosting my services? What if I am hosting my services in Windows Azure?
Firstly, this question is about MPNS (Microsoft Push Notification Service), not WNS (Windows Notification Service). They are two separate services, with WNS being now Microsoft's preferred platform.
Microsoft provides a list of MPNS-approved CA's (certificate authorities) here:
SSL root certificates for Windows Phone OS 7.1
The process for acquiring the certificate is roughly the same with all CA's. You need to create a CSR (certificate signing request) with your domain name as the certificate CN (common name), and send it to the CA. The CA charges a sum for certain validity period (typically 1, 2, or 3 years). Before the SSL certificate is issued, they normally do certain checks to ensure that you really own the domain name, e.g. by mailing the WHOIS owner of the domain and/or asking you to create a special DNS record.
Once you have your certificate, you need to install it as a client certificate in the server that makes the push notification calls to the MPNS servers. How do you do that, depends on your server architecture (.NET, Java, etc.).
http://www.verisign.co.uk/
you need a registered domain name and then you can register to buy a certificate, I think the cheapest I found for my app a few years ago was something like $99 but this may well be incorrect now.
Good Luck,