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
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.
When logging on to OWA using a browser, receive a 503 error. In the Fiddler trace will see a more detailed response status code:
503 Failed authentication on backend server: Unauthorized
On the Exchange Server, see the following System event log (intermittently):
Event 4 Security-Kerberos
The Kerberos client received a KRB_APP_ERR_MODIFIED error from the server exchangeserver$.
The target name used was HTTP/exchangeserver.ad.root.
This indicates that the target server failed to decrypt the ticket provided by the client.
I hope someone only receives this in a lab environment!
Here is a link to enable Kerberos logging, which could be helpful as well: https://learn.microsoft.com/en-us/troubleshoot/windows-server/identity/enable-kerberos-event-logging
After enabling Kerberos logging, would see the KRB_APP_ERR_MODIFIED error more frequently, whereas before would not be logged each time a logon attempt occurred.
The issue here (in the lab) was that a duplicate SPN for the Exchange Server in question was added erroneously to another server, causing a duplicate. This was due to trying to enable Kerberos delegation for a separate web application.
Although there could be a quicker way to do this, you can list the SPNs on each server to look for your erroneous exchangeserver record by running
setspn -l otherservername (this is a lower-case L)
And if you find that SPNs like http/exchangeserver or http/exchangeserver.ad.root are listed on another server (say 'otherservername'), you can carefully remove them by running
setspn -D http/exchangeserver otherservername
setspn -D http/exchangeserver.ad.root otherservername
I was able to logon to OWA immediately after the duplicate SPN was removed, without restarting any servers or services.
Check, if the bindings for Exchange Backend website in IIS is correctly configured. You can check this by visiting IIS console in the server and open bindings for Backend website for 443 port. See, if the certificate is assigned well
Also, check, if the Default website's binding is correct. It should have thirdparty SSL certificate assigned or the self signed certificate
If any of the bindings are incorrect, fix it and restart IIS (iisrest from cmd prompt). Check again
We have two Windows 2012 servers reside on the same subnet on domain "FACTORY".
And we have intermittent authentication issue(3rd party app) with users from domain "OFFICE".
During troubleshooting using nltest command, something which I don't understand.
Here is the output from the first Windows 2021 server:
nltest /dclist:OFFICE
Get list of DCs in domain 'OFFICE' from '\\DC01'.
You don't have access to DsBind to OFFICE (\\DC01) (Trying NetServerEnum).
I_NetGetDCList failed: Status = 6118 0x17e6 ERROR_NO_BROWSER_SERVERS_FOUND
Here is the output from the second Windows 2012 server:
nltest /dclist:OFFICE
Get list of DCs in domain 'OFFICE' from '\\DC02'.
You don't have access to DsBind to OFFICE (\\DC02) (Trying NetServerEnum).
List of DCs in Domain OFFICE
\\DC03 (PDC)
The command completed successfully
Why the 2nd Windows 2012 could get list of DCs in Domain OFFICE? Both servers are located on the same network subnet, both have the same network settings, no WINS. I can see that the nltest was using different DC (DC01 vs DC02) to get the result, which I also don't understand.
I was reading a lot of articles about the error ERROR_NO_BROWSER_SERVERS_FOUND, which pointed to "Computer Browser Service". However, this service is disabled on both servers.
The intermittent authentication issue has never been reported from the 2nd Windows 2012, so I would suspect this nltest result might contribute to that.
What's the domain topology?
What kind of trust is it?
Are there any error events from NETLOGON in the DC event logs on either side?
Does nltest /trusted_domains show the correct info on the FACTORY DCs
Does nltest /sc_query:OtherDomain show any errors on the Trusting side?
Same with netdom trust TrustingDomainName /domain:TrustedDomainName /verify on each of the DCs on each side of the trust? (Or you can check it in AD Domains and Trusts). Unlike nltest, this requires credentials.
Are all the required ports, including all the required RPC ports, open between all the DCs in each domain? And in Windows Firewall? The most important aspect is that the Trusting domain DCs must be able to get to the PDCE in the Trusted domain. At the very least, you need these ports: LDAP (389 UDP and TCP), SMB (445 TCP), Kerberos (88 UDP), RPC portmapper (135 TCP), DNS (53 UDP and TCP)
Have you tried DNS queries from all the DCs to see if you can resolve the SRVs on each side? e.g. nslookup -q=SRV _ldap._tcp.mydomain.com (and the same for _kerberos.tcp and _kerberos.udp)
Do any of the DCs in either domain have the same hostname? Or duplicate SIDs? If the DCs were built from a custom image, were they Sysprepped?
Is the time in sync on all DCs on both sides of the trust? (Within 5 minutes, maximum)
Any errors in NETLOGON.LOG? You can enable NETLOGON debug logging for richer information, but only leave it on for a short time.
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.
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.