I configured the Bus with the scripts below.
The new cert in the LocalComputer\Personal\Certificates cert store.
The sample app throws an authorizationexception :
'The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel. Inner exception {"The remote certificate is invalid according to the validation procedure."}
$SBRunAsPassword = ConvertTo-SecureString -AsPlainText -Force -String [PASSWORD];
$SBCertAutoGenerationKey = ConvertTo-SecureString -AsPlainText -Force -String [PASSWORD];
New-SBFarm -CertAutoGenerationKey $SBCertAutoGenerationKey -RunAsName 'server\user' -AdminGroup 'BUILTIN\Administrators' -PortRangeStart 9000 -TcpPort 9354 -FarmMgmtDBConnectionString 'Data Source=[SERVER]\SQLEXPRESS;Integrated Security=True'
Add-SBHost -FarmMgmtDBConnectionString 'Data Source=[SERVER]\SQLEXPRESS;Integrated Security=True' -RunAsPassword $SBRunAsPassword -CertAutoGenerationKey $SBCertAutoGenerationKey;
New-SBNamespace -Name 'DemoNameSpace' -ManageUser '[USER]';
If you're running your client application on a different machine than the server, then you need to import the CA into your your client machine to be able to trust the certificate ServiceBus presents.
This page has information on how to perform that:
http://msdn.microsoft.com/en-us/library/jj192993.aspx
Also, make sure that your client calls always use the fully qualified domain name of the machine (if your machine is domain joined). This is because the certificate that ServiceBus generates on install uses the FQDN of the box as the certificate's CN.
On a non domain computer you need to modify the url format and remove the domain component.
Related
I have a Mosca MQTT broker running on a node instance and I would like to encrypt all the incoming communications with SSL/TLS (MQTTs protocol) but without the client having to link any certificate to the connexion (I guess it has to do with self-signed certificates) just as https works. I want all my clients to connect just with credentials specifying the MQTTs protocol and the communication can be encrypted. I was using Amazon MQ just before and that's how it works so I want the same.
I can't figure how to configure properly Mosca to do so, I don't know what kind of certificate I must use.
I added the secure field in the configuration as shown here
For the certificate I tried to create a self signed certificate as shown here
I also tried with certbot certificates (Let's Encrypt) registered for my domain name : mq.xxx.com .
I'm running everything on a ec2 (ubuntu 18) and my network and firewall are open for 1883 and 8883. My key and cert are at the root of my project where the deamon is running with good rights and ownership. I know my instance access them correctly.
new mosca.Server({
port: 1883,
secure: {
keyPath: "./privkey.pem",
certPath: "./cert.pem"
},
backend: {
type: 'redis',
redis: require('redis'),
host: "localhost",
port: 6379,
db: 0,
return_buffers: true,
},
persistence: {
factory: mosca.persistence.Redis
}
});
My server is running and working with simple mqtt on port 1883 but when I try to connect with ssl/tls with a client on port 8883 specifying that the server uses self-signed certificates (I tried with MQTT.fx) it fails saying : "unable to find valid certification path to requested target".
I can't make my head around this issue, I think somehow the client cannot "accept" or "verify" the certificate provided. Maybe I'm providing the wrong key or certificate to Mosca but there is only one of each resulting openssl or certbot. Maybe I created wrong but I follow many tutorials on the very same subject such as this one
What kind of certificate do I need to do ?
Is there something more to do with them ?
Thank you.
If you are using a self created certificate then the client will need a copy of certificate that signed the broker's certificate. This certificate will be added to the list of trusted sources so it can prove the broker is who it claims to be.
If you do not want to / can not distribute a certificate then you will need to use a certificate for your broker that is issued by CA (Certificate Authority) whoes signing certificate you already have (bundled into the OS/client that you are using).
The Lets Encrypt signing certificates should be bundled into most OSes by now but they are also cross signed by IdenTrust again who's certs should be bundled with most OSes. If you are having problems with the Lets Encrypt certs then I suggest you ask a new question with the exact details of how you configured mosca with those certs and more details of how you are configuring MQTT.fx and the errors you receive.
How Safenet Luna SA HSM clients are verified when the clients are registered using hostname ?
Safenet Luna HSMs use certificate based authentication for clients. The certificate must be copied to the HSM and have a filename that matches the hostname used in the client register command on the HSM.
A typical process for registration is:
Copy the server certificate to the client installation.
scp admin#10.41.4.98:server.pem /usr/lunasa/cert/server
Register the server locally
vtl addServer -n 10.10.10.10 -c /usr/lunasa/cert/server/server.pem
Create the client certificate on the client:
vtl createCert -n HOSTNAME
This creates a certificate and private key in the cert/client directory named:
HOSTNAME.pem (certificate)
HOSTNAMEKey.pem (private key)
Copy the client certificate to the Luna SA HSM using scp.
scp /usr/lunasa/cert/client/HOSTNAME.pem admin#10.10.10.10:
On the HSM, register the client and assign it to a partition.
client register -client HOSTNAME -hostname HOSTNAME
client assignPartition -client HOSTNAME -partition PARTITIONNAME
On the client, verify that the client is registered and operating properly:
$ vtl verify
The following Luna SA Slots/Partitions were found:
Slot Serial # Label
==== ======== =====
1 123456789 myPartition1
Looking at you comments after Keith helped with the process of trust/cert exchange.
Below is the command that you might need-
ntls ipcheck disable
HSM verifies clients based on the NTL ((Network Trust Link) connection. Establishing NTL connection is mandatory before clients makes a call to HSM via Crytoki. The procedure to establish NTL connection is explained by #Keith Bucher
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.
I am writing a WCF service where I need to access the Hash Code of client certificates that are used to connect to the service.
I am looking for a property or method similar to Request.ClientCertificate from ASP.NET 2.0 days but cannot find anything that allows easy access to the client certificate.
Our service is set up such that it is running with SSL using basicHttpBinding and security mode of "Transport".
IIS has been set up to Require SSL and Accept certificates.
One thing to note is that our server certificate used to secure the endpoint is from a different CA to that of the client certificates - the client certificates are intended to be validated solely through custom code (thus the need to get the hash code of a connecting certificate).
I have created a custom implementation of the IDispatchMessageInspector to see if there is any access to a client certificate from there but to no avail.
Has anyone attempted this and had success before?
Looks like what the best option for you would be to implement a custom Certificate Validator for your service. This is basically a class that derives from X509CertificateValidator and is then registered through the config file.
There's more complete information on how to do this on this article.
For reference if anyone else attempts to apply client certificate authentication the following steps were required to get it to work (we are using basicHttpBinding within WCF for this instance and running in a local instance of IIS):
Set up IIS to use a HTTPS binding for the site and secure this in IIS with a server certificate
Within IIS change the SSL Settings for your site to Require SSL and Require client certificates (It must be Require - Accept will not work)
Within the WCF configuration ammend the basicHttpBinding and set security mode to "Transport" and the transport clientCredentialType to "Certificate"
Ensure that the root certificate (the one used to create any client certificates) is within the "Trusted Root Cerrtification Authorities" for the Local Computer on which IIS is running.
NOTE If you are in a development environment you may need to generate your own root certificate, the makecert command line application is very useful for this; simply run the following command:
makecert -n "CN=My Test Auth" -r -cy authority -a sha1 -sv "My Private Key.pvk" TestAuth.cer
This creates a certificate called TestAuth.cer (which needs to be added to the Computer's "Trusted Root Cerrtification Authorities") and a private key file called "My Private Key.pvk".
Now to generate a client certificate you can run this command:
makecert -a sha1 -n "CN=myConnectionCert" -ic "TestAuth.cer" -iv "My Private Key.pvk" -ss My
This created a certificate with a subject of myConnectionCert and adds it to your personal certificate store - when you now access the site (to view the service page for example) IE should prompt you to select the certificate - chose the one you have just created and you should see the service page as normal.
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..