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.
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.
Short story
I'm trying to send a POST request from a PL/SQL script using the utl_http utility in Oracle. I've been able to send the request using http, but not https. I've added what I thought was the necessary certificates to a Oracle Wallet, and I believe they are being imported and used (but in all honesty, this is a little hard to verify). My current assumption is that calls from our DB server are passing through a proxy server, and that that is somehow messing up some part of the https / certificate functionality.
Supporting evidence (possibly?): I tried to make calls (POST requests) to a dummy service at webhook.site. Again, I got this working with http, but not https - the latter results in a cert validation error.
I then tried to replicate the behavior using postman, and that basically produces the same result, unless I fiddle around with the settings:
Initial Postman result:
Could not get any response
There was an error connecting to https://webhook.site/950...
Disabling SSL verification
Under the Post man settings, I turned off SSL Certificate Verification, and tried again. This time, I got a 200 OK response, and confirmed that the webhook received the post request fine.
It seems clear that the error is due to a missing cert, but I can't figure out which, or how to configure it. My assumption is that if I can get this to work for a webhook-url from Postman (without disabling cert verification), then I should also be able to get it to work from PL/SQL later.
When I look at the webhook site in a browser and inspect the certs, the webhook cert is the lowest cert (leaf node?). Above it there is one intermediate cert related to the company I'm working for, and then a root cert also related to the company. The root node is named something like "Company Proxy Server CA" - So I'm assuming the proxy somehow manipulates my requests and inserts it's own cert here.
I've tried downloading all of these certs and importing them into my cert store, as well as importing them under the Postman settings (under Certificates) in various combinations, but nothing seems to make any difference; all attempts at posting with HTTPS produces the following error in my Postman Console:
POST https://webhook.site/9505...
Error: unable to verify the first certificate
Any ideas about how to resolve this, or at least obtain more information about what to do would be greatly appreciated.
Switching OFF "SSL Certificate Verification" in Postman only means that it (i.e. Postman) will not check the validity of SSL certificates while making a request. Meaning that it will just send the certificates as they are. Because your connection fails if the setting in ON, this means Postman cannot verify the validity of your certificates.
This is most likely the case with the actual service you're trying to POST to, they cannot verify the certificates. Is that service outside your company network? And is it a public one or one owned by your company? Where is that service hosted? What certificate do they need?
BTW, TLS client certificates are sent as part of establishing the SSL connection, not as part of the HTTP request. The TLS handshake (and exchange/validation of client and server certificates) happens before any HTTP message is sent.
I'm thinking this might be a blocked port issue.
You said... ""Company Proxy Server CA" - So I'm assuming the proxy somehow manipulates my requests and inserts it's own cert here."
That means your client software needs your Company Proxy Server CA in its trusted certificates list. If that client's list is that of the oracle wallet...
https://knowledge.digicert.com/solution/SO979.html
This talks about how to do that.
Also, if your system running postman has a non-oracle based wallet trusted certificate (probably the operating system?) you'll have to execute something like adding the trust to your account on the workstation
https://www.thewindowsclub.com/manage-trusted-root-certificates-windows
in order to have the proxy server certificate trusted.
Once the certificate you're making the connection with has a root of trust per the effective configuration of the client being used, then you'll be able to verify the certificate.
A couple of possible issues:
The server doesn't actually support HTTPS. Connect a browser to the URL that you POST to, and see if you receive a response. (It looks like you already did this, but I'm documenting it for completeness.)
The server uses the Server Name Indication (SNI) extension to determine what certificate chain to send back, but your POSTing client doesn't send that extension. You can identify this case by looking up the IP for the host you're POSTing to, then going to https://nnn.nnn.nnn.nnn/ (obviously use the IP here, instead of the literal string 'nnn.nnn.nnn.nnn') in your browser, and checking the certificate chain it returns. If it is not the same as you get from step 1, this is your problem, and you need to figure out how to either get SNI support in your Oracle PL/SQL client or get the POST endpoint exposed on that hostname. (alternatively, you might be able to use these certificates to prime your Oracle Wallet, but they might have an issue with the hostname in the certificate not matching the hostname you connect to.)
You have a proxy in the way. I don't think this is what's going on, since that would basically only cause problems if you were doing client-side certificate authentication. (If this is the problem or is a condition, you need to import those certificates into your trusted wallet; you also need to ensure that the server you're posting from is going through the same proxy. Otherwise, you need to ensure that the certificate authority for the proxy that the machine actually running the code sees is in the wallet. This may require the assistance of the system/network administrators who run that machine and its connection to the network.)
HTTPS is a finicky beast. Many, many things must work exactly correctly for TLS connections to work and the certificates to correctly verify (the TLS port must respond, the client and server must agree to speak the same version of TLS, the client and server must agree to use the same cipher combination, the certificate chain presented by the server must be issued by a CA the client recognizes, and the leaf certificate in that chain must certify the name client requested).
SNI is needed to support multiple names on a single host without messing with the certifications of other names on the same host. Unfortunately, SNI is one of those things that has been standardized for over a decade (RFC 3546), but many enterprise-grade softwares haven't implemented.
Having some trouble with Domino server as client to a Web Service
Hope someone can answer a pretty easy question, but the easy question dont have a answer some I can find.
There is lots of Root Certificates in NAB
and there is also some common Root Certificates in every *.kyr file you create in certsrv.nsf for your seerver certificates.
I get an error from SSL_DEBUG that says
[108C:005C-0D8C] 2015-12-15 19:07:19,34 SSLCheckCertChain> Invalid certificate chain received
[108C:005C-0D8C] Cert Chain Evaluation Status: err: 3659, Cannot establish trust in a certificate or CRL.
It is pretty obvious what is the problem, I need to include a missing Certificate.
But I like to know if Domino is using the *.kyr file or if it is using the Certificates in the NAB when establishing the connection to the remote server.
Anyone know how Domino acts here ?
/Stefan
You have to find out the TLS certificate chain and add all public TLS certificates as trusted internet certificates to you domino directory.
Find out Certificate Chain
Use on of this Tools:
For internal and external server SSLyze
sslyze.exe <servername>:443 --certinfo=basic
Take a look at Certificate Chain Received:
For external server SSL Labs
Go to the section "Certification Paths"
Download public certificates from CA-Webpage or get from your internal CA responsible person.
Step-by-Step Domino Configuration
Import Certificates
Importing an Internet certifier into the Domino Directory
Cross Certificate Certificates
Server: Choose your Admin Server or server where the Domino CA (not SSL CA) is hosted.
Certifier: Choose your certifier ID or your Domino CA
Creating an Internet cross-certificate in the Domino Directory from a certifier document
Java/LotusScript Side
The Java or LotusScript Consumer has to be told to accept CA security (stub.setSSLOptions(PortTypeBase.NOTES_SSL_ACCEPT_SITE_CERTS);)
Examples based on Creating your first Web Service provider and consumer in LotusScript and Java.
Java
HwProvider stub = new HwProviderServiceLocator().getDomino();
stub.setSSLOptions(PortTypeBase.NOTES_SSL_ACCEPT_SITE_CERTS);
String answer = "" + stub.HELLO("world");
System.out.println("The answer is : " + answer);
LotusScript
Dim stub As New HwProvider()
stub.setSSLOptions(NOTES_SSL_ACCEPT_SITE_CERTS)
MessageBox stub.Hello("world")
Further Information
Question "Create cross certificate for Domino Java agent?" is similar but not a duplicate. It shows further aspects.
Thanks for your input, but that did not solve the problem.
I got solved trough
- downloading KYRtool
- install in /Domino folder
- include the Root certificate(SHA2) from Web Service domain into existing .kyr file
- restart http task
So conclusion is that it is the the .kyr file that is handling all stuff in outgoing connections
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.
We are trying to get MSMQ working over HTTPS. Messages sent over the internet to an Windows 2008 R2 server sitting on the cloud at rackspace works correctly when sent via HTTP. We have a certificate created for our domain and can access the web server via http and https with no problems. We are trying to use the same certificate for MSMQ, but it does not work. This is the explanation from Microsoft in their documentation, and is exactly what we experience. When we use http, it works, but when we use https, then we get an error in the event log that the certificate does not match the name of the destination. Messages then sent via https accumulates in the outgoing queue.
The full article is here : http://technet.microsoft.com/en-us/library/cc736680%28v=ws.10%29.aspx
"A server certificate obtained from a CA can be issued to the NetBIOS name or full DNS name of a computer. However, when HTTPS messages are sent, the destination specified in messages must be identical to the computer name in the recipient's server certificate. Thus, when only the NetBIOS name of the destination (for example, with a direct format name of the form DIRECT=$/q1) is used to send messages within the same forest over an intranet to a computer whose server certificate contains the full DNS name, authentication fails. Consequently, when Message Queuing tries to create an SSL session, it receives a warning that the name in the certificate does not match the name of the destination, and the messages sent in this way accumulate in the outgoing queue."
Our server name and Netbios name is different from the DNS name that points the IP Address to our website domain. We tried to change the computer name to be the same as our website domain to get it to correspond with the certificate domain address, but it does not work as periods are not allowed in the server name.
Any help will be appreciated.
Please assist