Good afternoon,
I'm getting the following error trying to use a BizTalk send port to talk to a web service:
"System.InvalidOperationException: Cannot find the X.509 certificate using the following search criteria: StoreName 'My', StoreLocation 'CurrentUser', FindType 'FindByThumbprint'
The send port is configured as type 'WCF-WShttp', 'Transport' security mode, 'Certificate' credential type.
I have a self signed certificate that has the same thumbprint value as shown in the bizTalk configuration dialog. I've checked the file shows the correct thumbprint and it is not expired.
I've tried installing it in the all the following stores:
"Current User": Personal, Trusted Publishers, Trusted People, Trusted CA's
"Local Computer": Personal, Trusted Publishers, Trusted People, Trusted CA's.
When I go to the wcf send port configuration in the BizTalk management console it allows me to browse available certs. Our cert appears and lets me select it.
I made sure the service account for biztalk is added to the cert permissions.
Any suggestions?
Thanks!
The client certificate needs to be installed in BizTalk host user account certificate "Personal Store", also make sure any root certificate (if any) is in trusted store and then set it on adapter configuration.
Following these procedures should work. https://msdn.microsoft.com/en-us/library/gg634534(v=bts.70).aspx. Probably the most important thing to note is that you must be logged on to the server with the actual account that is running the adapter handler's host instance service. And for a self-signed certificate I think you just need to add it to the Trusted Root CAs for that account too.
Did you copy the thumbprint directly from the mmc to your BizTalk Send Port.
First try to copy it to notepad++ and check if you see any special characters.
If that's the case remove the special characters and then copy that thumbprint to your BizTalk Send Port.
Related
I am rather confused by the purpose of the trustore file in a tomcat server.
I.e use of the truststoreFile parameter when setting up a TLS enabled connector.
According to the tomcat docs:
truststoreFile
The trust store file to use to validate client certificates. The
default is the value of the javax.net.ssl.trustStore system property.
If neither this attribute nor the default system property is set, no
trust store will be configured.
To me this is telling me that for an inbound connection to my tomcat server, this is where I would store certificates that a client would present. (e.g. a users browser)
Would I really put in 3rd party CA certificates here or other 3rd party server certificates, if my tomcat server wants to make an outbound connection to a TLS enabled server (e.g. an LDAPS server)
As per my understanding the place to do this is the cacerts file.
Is my understanding of the truststore wrong?
Yes, you are right, it is quite confusing.
If you need to make an outbound connection a 3rd party, you need to add the certificates to cacerts.
There is a very popular "signing, validation, etc." service for government-owned companies here in Spain, #firma, that just changed its wildcard server certificate and we had to add it to cacerts.
I have an IIS 7.5 web server with an SSL certificate setup as follows:
Select "Default Web Site" -> Bindings:
Type: https (all other types removed)
IP address: All Unassigned
Port: 443
SSL certificate: mycert.pfx
I have a C# client application that accesses the URL for the site above. If the user just tries to connect, the connection fails because they do not have the mycert.pfx certificate file installed.
When the clients were on Windows 7, we just told them to open the URL in Internet Explorer. This required them to "Proceed Anyway - Not Recommended". The URL bar would turn red, and the user could follow steps to download/install the certificate with Internet Explorer. After that, the application always worked.
In Windows 10, the default Internet Explorer does not offer a "Proceed Anyway - Not Recommended" link. If I keychain the mycert.pfx file to their machine and install, the client application connects to the server and everything works.
Finally, here's my question: How do people handle certificate file deployments in a large commercial environment? The .pfx certificate has to be renewed every year, so just adding it to the application installer is only a short term fix. Is there a typical way to install/update .pfx files for clients?
Randy
Your pfx files should never be shared with the client. the public key chain is shared with the client. PFX file contains the private key of the certificate which you have procured from a CA which must never be shared.
The client application will verify the certificate chain received from the server with the public root and intermediates which are pre installed in its certificate store.
I've read quite a few articles on the client certificate authentication in IIS but they mostly talk about the Required mode for the client certificate. In this case, the authentication is fully done on the web server side and the user is redirected to the error page in case the certificate is missing or invalid. What I need is to configure IIS to check the client certificate if it exists and pass the results as http headers to my backend. It can be easily done with nginx or apache web servers. The client authentication can be set up as optional. Then, the web server checks the certificate and pass the results of the check as SSL_CLIENT_CERT (PEM representation of the certificate) and SSL_CLIENT_VERIFY (the result of the check - SUCCESS, NONE,...) headers to the application backend. So, on the backend part, I can read the headers and use the values to do the actual authentication -- find a user in the database, issue an auth token. Is it possible in IIS? If yes, is there any documentation on how to bypass the certificate and the check state as http headers?
After a while, I'm writing an answer to my question.
IIS has to be set up with ARR extension to act as a reverse proxy. Then, the client certificate authentication can be enabled for the default web site. Here are several links to instructions how to achieve it:
https://blogs.msdn.microsoft.com/benjaminperkins/2014/06/02/configure-application-request-routing-arr-with-client-certificates/
https://blogs.msdn.microsoft.com/asiatech/2014/01/27/configuring-arr-with-client-certificate/
and couple of links to very solid explanations of the SSL/TLS handshake and certificates in general:
https://blogs.msdn.microsoft.com/kaushal/2013/08/02/ssl-handshake-and-https-bindings-on-iis/
https://blogs.msdn.microsoft.com/kaushal/2013/01/09/self-signed-root-ca-and-intermediate-ca-certificates/
https://blogs.msdn.microsoft.com/kaushal/2015/05/27/client-certificate-authentication-part-1/
Basically, the Application Request Routing (ARR) extension should be enabled for the IIS to act as a proxy. Then, you set up proxy bypass routes. Next, you need to set up a valid server certificate for the IIS server and use it in the Default Web Site https bindings. The certificate should be issued by a CA which certificate should be placed into the Trusted Root Certification Authorities and Intermediate Certification Authorities of the Local Computer. Then, you should require SSL in the SSL settings of the Default Web Site with the client certificates setting equal to Accept. In this case, any client that connects to the web server will be asked for a valid client certificate that has been issued by the same CA as the server certificate.
Actually, IIS sends a list of distinguished names of root issuers that are trusted by the web server to the client browser. The browser finds an intersection of this names with client trusted certificate issuers and looks for valid certificates that have been issued by the issuers in the intersection. After that, the user selects one of them (or none) and the selected certificate is checked against the CA certificate. If the certificate passes the check the request is "redirected" to the backend application with the certificate in the X-ARR-ClientCert header. The name of the header can be changed in the Server -> Configuration Editor -> system.webServer/proxy -> clientCertHeaderName IIS parameter. In case the user selects (or has) none of the required certificates, the request is "redirected" to the app backend without the header.
Seems, there is no need in the SSL_CLIENT_VERIFY header with the state of the check at all. If the certificate is valid it is passed in the header. If the certificate is missing the header is empty. If the certificate is provided by the client but is invalid then the request fails and is not "redirected" to the backend app server at all. Seems, it is a rare case but I have an example.
Imagine, a server certificate is issued by a CA with a distinguished name XXX, and there is a client certificate YYY (on the client computer) that is issued by a CA with the distinguished name XXX but those CAs are not the same (one or both of them are self-signed). In this case, the YYY certificate is present in the certificate selection dialog that is shown by a browser but the certificate doesn't pass the further validation against the real web server CA.
That's it. Also, seems IIS has no way to require (or accept) a client certificate for some app endpoints (addresses) only. I haven't found any other option apart from enabling in for the whole web site.
IIS ARR can also be configured with a client certificate for the backend or upstream server. In this case users connecting to this IIS do not need to provide the certificate as it will be attached by IIS automatically.
This configuration is available on IIS server level only.
I have my website https://www.MyWebSite.com running on port 433. But I also have a admin login that only are available from the office local network http://MyServer:9999/Login.aspx. Both addresses points to the same site but different bindings.
Is it possible to get the one on port 9999 to use https? I tried creating a self signed certificate in IIS but my browser still complained, even though I exported the certificate and stored it in my CA Trusted root.
So just to sum everything:
My regular site: https://MyWebSite.com <-- working fine
My admin login, only accessible via local network: http://MyServer:9999/Login.aspx works fine.
When adding a selfsigned certificate issued to "MyServer" (not MyWebSite) and add the new binding on port 9999 I though to the website but Chrome is giving me a warning NET::ERR_CERT_COMMON_NAME_INVALID, even though the cert is Issued To MyServer and are trusted
Is it possible to get the one on port 9999 to use https?
yes it is possible to setup another port with selfsigned
certificate.
Normally Selfsigned certificate will have fully qualified machine name
e.g. machinename.subdomain.domain so you have to browse using https://machinename.subdomain.domain:9999/
Please double check what error you are running into ,In chrome
Your connection is not private
Attackers might be trying to steal your information from in08706523d (for example, passwords, messages, or credit cards). NET::ERR_CERT_COMMON_NAME_INVALID
in IE,you may get
There is a problem with this website’s security certificate.
The security certificate presented by this website was issued for a different website's address.
Security certificate problems may indicate an attempt to fool you or intercept any data you send to the server.
In that case,assuming you have given hostname as * in IIS binding, and also installed the selfsigned certificate installed your "Root Certification Authorities " You should be able to browse to
https://machinename.subdomain.domain:9999/ without any issues
I have a unique situation where I need to implement client certificate authentication over HTTPS between IE browser and IIS 6. The browser and IIS are separated by a firewall that only allows the browser to connect to IIS on the SSL port.
We have an internal certificate server on the same network as IIS. I've generated an SSL server cert for IIS and that is installed. I configured IIS to only allow SSL, require client certificates.
The limitation here is the browser machine is on a disconnected network, so I can't go to the CA's http://caserver/CertSrv URL and request a client cert like you normally would.
I figured if there were a way that I could generate a CSR against the Root CA's public key, I can copy it to the CA server to generate the client cert. But, there appears to be no provision in IE or the Certificates MMC to do this. The Certificates MMC seems to require a direct connection to the CA.
Has anyone solved this before?
FYI, All servers referenced run Windows Server 2003.
Update: Thanks to Jonas Oberschweiber and Mark Sutton for pointing out the CertReq.exe command line tool. Using this, I've generated a CSR, and consequently a client certificate that installs successfully. However, IE is apparently not sending this client cert when accessing the IIS server in question; it still generates a 403.7 "Forbidden: SSL client certificate is required." I suspect that the reason is that the Subject field of the client cert does not match the user id of the account running IE, thus perhaps not sending a mismatching client cert. The Subject matches that of the user I used to submit the CSR and generate the client cert on the other end of the firewall.
Does the Subject field matter? Is there something else I need to do to enable IE to send this cert?
Use the certreq command on your client as follows
certreq -new -f filein c:\certrequest.req
Here is and example of the filein
[Version]
Signature="$Windows NT$"
[NewRequest]
Subject="CN=dc1.extranet.frbrikam.com"
EncipherOnly = False
Exportable = False
KeyLength = 1024
KeySpec = 1
KeyUsage = 0xA0
MachineKeySet = True
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
ProviderType = 12
RequestType = CMC
[RequestAttributes]
CertificateTemplate=TLSServer
Replace the CertificateTemplate with the name of your certificate template
Once you have your request file you need to take it to the certificate authority on a usb stick and use the web enrolment interface as usual to process the request file.
Take the output certificate back to the client open it and click install.
You sound like you have already tried a couple of things so my guess is that you are already aware of these, but I'm going to post them anyway, just in case: Certificate Command Line Tools. I am not sure, however, if they do what you want.
Go the http://caserver/CertSrv site that you mentioned using a 3rd computer that can see the CA server. Select the 3rd option, download a CA cert, cert chai, or CRL. On the next page select 'Download CA Certificate Chain', which will download the p7b file. Using a flash drive (or email, etc) transfer this to the other computer which will allow you to import it into the trusted root servers in IE.
http://technet.microsoft.com/en-us/library/cc787796.aspx
Suggestiong for the update, just in case - what is the trusted cert list of in the server?
Subject DN being the same as Windows username has never been a problem for me - although I don't use IIS much. However, somewhere in IIS there is sure to be a trusted certificate list. This error sounds to me like the server's trusted certs list does not include the CA or Root CA that issued the client certificate.
This is particularly true if you never get a certificate selection popup window in IE when you hit the IIS server - even though you have a certificate configured in your IE cert store. That means that the client hit the server, the server gave a list of trusted certs and the client didn't have a cert that fit the list. So the SSL session went to the Forbidden error state.
If the certificate selection window popped up, and you selected and sent the cert, there may be other configuration problems on the server side..