I wish to bind a self signed certificate to a port for developing my self hosted wcf application, but I always fail.
Steps I've done:
created the root certificate:
makecert.exe -a SHA256 -n "CN=DemoCA" -r -sv TempDemoCA.pvk TempDemoCA.cer
created the client cert:
makecert.exe -a SHA256 -sk Demo -iv TempDemoCA.pvk -n "CN=DemoTempCert" -ic TempDemoCA.cer DemoTemp.cer -sr currentuser -ss My -sky exchange
imported the root cert with mmc.exe(as Administrator) into local computer certificates
imported the client cert with mmc.exe into local computer certificates
added the private key to the client cert, because it didn't have the key icon:
certutil -repairstore my "MyKeyHash"
Added a firewall entry:
netsh http add urlacl url=https://+:9003/ user=domain\user listen=yes
tried to bind the certificate to the port(as admin):
netsh http add sslcert ipport=0.0.0.0:9003 certhash=MyCertHash appid={NewGuid} clientcertnegotiation=enable
But step 7 failed with error 1312.
SSL Certificate add failed, Error 1312
A specified logon session does not exist. It may already have been terminated.
All I found out by googling, doesn't solve my problem, e.g.:
- import via mmc and not certmgr.msc
- create a new certificate
- KB Hotfix
Interesting fact: binding the existing "localhost" client certificate to a port works fine.
What am I doing wrong?
Thanks in advance.
The solution was that the common name has to be the same as the used domain of the service. In my case localhost did the trick.
Related
I am trying mtls authentication in MQTT. I am using mosquitto to achieve this. When I created a server and client certificate from the same CA then the connection was successful. But if I use a different CA for creating a client certificate then it's failing with the below message
Client null sending CONNECT
OpenSSL Error[0]: error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca
Error: The connection was lost.
Is it mandatory to use the same CA for both client and server certificates in mtls?
Mosquitto.conf
listener 8883
certfile C:\\server.crt
keyfile C:\\server.key
require_certificate true
cafile C:\mqtt-ssl-demo\ca.crt
allow_anonymous true
Running broker using
mosquitto -c "C:\Program Files\mosquitto\mosquitto.conf"
Subscribe with a client with a certificate signed by server cert ca [SUCCESS]
mosquitto_sub --cafile C:\mqtt-ssl-demo\ca.crt -t test -d -h Computername -p 8883 --cert C:\mqtt-ssl-demo\client.crt --key C:\mqtt-ssl-demo\client.key
Subscribe with a client with a certificate signed by other ca [FAILURE]
mosquitto_sub --cafile C:\mqtt-ssl-demo\ca.crt -t test -d -h Computername -p 8883 --cert C:\mqtt-ssl-demo\otherclient.crt --key C:\mqtt-ssl-demo\otherclient.key
Created certificate using Mosquitto SSL Configuration -MQTT TLS Security
The important thing to realise here is that the CA file passed to the broker as part of it's config is used to verify the certificate of any connecting clients.
Where as the CA file passed to the client (mosquitto_sub) is used to verify the certificate the broker presents.
So if you are using different CAs then these files need to be different, it's not clear from what you've posted which CA certs you are using where.
I know the server need a self-signed CA. But how can I generate a CA, and where can I put it to make server's PowerShell 2.0 work? And what is CN matching?
The following is what happens when I run the command winrm quickconfig -transport:https:
WinRM already is set up to receive requests on this machine.
WSManFault
Message
ProviderFault
WSManFault
Message
Error number: -2144108267 0x80338115
Cannot create a WinRM listener on HTTPS because this machine does not
have an appropriate certificate. To be used for SSL, a certificate
must have a CN matching the hostname, be appropriate for
Server Authentication, and not be expired, revoked, or self-signed.
Unless you want to go to the trouble of setting up a full-fledged single-tier or two-tier PKI infrastructure (which would be a topic for ServerFault rather than StackOverflow) you could make do with makecert.exe to create a self-signed CA certificate and host certificates signed with it.
Create the CA certificate like this:
& makecert.exe -pe -r `
-n "CN=TestCA" `
-ss my `
-sr LocalMachine `
-a sha256 `
-sky signature `
"TestCA.cer"
Then create certificate for the host:
$cn = if ($env:USERDNSDOMAIN) {
"$env:COMPUTERNAME.$env:USERDNSDOMAIN"
} else {
$env:COMPUTERNAME
}
& makecert.exe -pe `
-n "CN=$cn" `
-ss my `
-sr LocalMachine `
-a sha256 `
-sky exchange `
-eku 1.3.6.1.5.5.7.3.1 `
-in "TestCA" `
-is my `
-ir LocalMachine `
-sp "Microsoft RSA SChannel Cryptographic Provider" `
-sy 12 `
"$cn.cer"
The CN (Common Name) is the subject of your certificate and for host certificates must match the computer's FQDN.
If you want to create host certificates for other hosts than your local computer you need to set $cn to the name/FQDN of the other computer. To get the certificate and private key to the destination computer export both from your certificate store (<serial> is the serial number of the certificate):
& certutil.exe -exportPFX -f -privatekey -p "password" "<serial>" computer.pfx
Copy computer.pfx to the computer for which you generated the certificate and import it like this:
& certutil.exe -importPFX -f -privatekey C:\path\to\computer.pfx
You'll be prompted for the password you specified when exporting the certificate.
On all machines that should use certificates signed by your TestCA you need to import TestCA.cer under Trusted Root Certification Authorities for the computer account.
& certutil.exe -f -addstore ca C:\path\to\TestCA.cer
Note that makecert.exe isn't available as a separate download anymore, but you can get it from the Windows SDK (download the ISO image and run the SDK Tools installer from the subfolder \setup\WinSDKTools).
Note also that using a makeshift CA like that is strongly discouraged for any kind of production environment.
I know its bad to just share a link, but I'm on a mobile and its better than nothing and uses all/mostly PS commands.
https://4sysops.com/archives/powershell-remoting-over-https-with-a-self-signed-ssl-certificate/
I am developing a WCF DataService that's self-hosted inside a Windows Console Application. I want to activate my service over Https (i.e. SSL) instead of Http. How can I do that?
Thanks
First Creating a CA Certificate on Windows (use Visual Studio Command Prompt):
makecert -sv SignRoot.pvk -cy authority -r signroot.cer -a sha1 -n "CN=Dev Certification Authority" -ss my -sr localmachine
Now put the certificate in the "Trusted Root Certification Authority" in Windows Key Store. That can be done through MMC. To do that: Run... -> Type "mmc" -> enter -> choose the "Certificates" console -> Find your created certificate in the Personal store and move it to the Trusted Certificate Authority store.
Now we create an exchange certificate signed by the CA certificate:
makecert -iv SignRoot.pvk -ic signroot.cer -cy end -pe -n CN="localhost" -eku 1.3.6.1.5.5.7.3.1 -ss my -sr localmachine -sky exchange -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12
NOTE: The EKU OID is for Server Authentication
NOTE: the CN (Common Name) should be identical to the name by which the service will be called.
Now we add an Https endpoint to the data service. That can either be
1- Through the web.config file of the service, in which we'll have to enter a service endpoint:
<endpoint address="https://localhost:8888/" binding="basicHttpsBinding" contract="System.Data.Services.IRequestHandler"></endpoint>
2- Or with adding an endpoint programmatically using the "AddServiceEndpoint" of the DataServiceHost object:
host.AddServiceEndpoint(
new ServiceEndpoint(ContractDescription.GetContract(typeof(TestODataService.DemoDataService)))
{
Address = new EndpointAddress("https://localhost:8888/"),
Binding = new WebHttpBinding(WebHttpSecurityMode.Transport),
Contract = ContractDescription.GetContract(typeof(IRequestHandler)),
}
);
NOTE: The binding in the second method is necessarily WebHttpBinding with Transport security. While in the web.config method, it can be either basicHttpsBinding, or a webBinding with bindingConfiguration that enable transport security.
Now we bind the exchange certificate with the port of the service. In order for the WCF web server to respond to clients with the exchange certificate, we need to bind the certificate to the address of the service, using the netsh command:
netsh http add sslcert ipport=0.0.0.0:8000 certhash=0000000000003ed9cd0c315bbb6dc1c08da5e6 appid={00112233-4455-6677-8899-AABBCCDDEEFF}
NOTE: the certhash is the thumbprint of the exchange certificate, and the appid is the GUID of the hosting application found in the AssemblyInfo.cs of the project. The ip 0.0.0.0 binds to all ip address, and the port is the port of the service. This command is required to be used only once for each address.
NOTE: Some mobile devices may not be able to verify the identity of the service when called using the ip address of the service, even if the exchange certificate have the CN set to the ip address of the service. In this case the CN of the certificate should be a domain name.
NOTE: in order for the mobile device to trust the exchange certificate of the service, the CA certificate should be installed on the mobile in the Trusted CA Certificate store.
NOTE: Some browsers (e.g. Chrome) will object that the certificate is issued for localhost which is a name only used in your local network. This will not occur if you set the CN to a domain name.
Reference: http://www.codeproject.com/Articles/24027/SSL-with-Self-hosted-WCF-Service
I have been having this issue for about 2 weeks. I have done a lot of research and tried different ways but no joy. I have a development website on my computer (Windows 7 Pro) with sql server 2008 r2 and using IIS 7.5. There is an actual development server running the database and Webserver but because of my location I cannot use the main development site. I issued a self signed Trusted Root Certificate:
makecert -r -pe -n "CN=ROOT AUTHORITY" -ss my -sr CurrentUser -a sha1 -sky signature -cy authority -sv ca.pvk ca.cer
Then I install that into the trusted root on the local computer. After that I created a certificate for IIS to use.
makecert -pe -n "CN=example.website.name.com" -a sha1 -sky exchange -eku 1.3.6.1.5.5.7.3.1 -ic ca.cer -iv ca.pvk -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12 -sv server.pvk server.cer
Then I create the .pfx file for IIS
pvk2pfx -pvk server.pvk -spc server.cer -pfx server.pfx
After I do the above. I import the certificate into IIS and then I bind the website to the SSL certificate (server.pfx)
After all that is done, I go on the website https://example.website.name.com and I get 403.7 forbidden.
Can somebody please help me out with this issue?
take a look at some of these pitfalls...
Server Issue #1 - The client cert passed in has 1 or more certification paths that do NOT exist on the server. Open the cert go to certification path (tab) and make sure each of the root authorities are in the SERVERS trusted root certificate authorities. Note, you DO NOT need to install the cert on the server just the root authorities public keys under Certificates (Local Computer) \ Trusted Root Certification Authorities.
Server Issues #2 (previously mentioned solution) - In IIS, for the site, make sure the SSL Settings are set to Accept OR Require (never ignore). The benefit of using Require is that the IIS logs will show you are 403 7 error where as Accept will just get your the IsPresent == false but with a 200 http code.
Client Issue #1 - Same as server issue #1, got to trust those authorities!
Client Issue #2 - You have the trusted root authorites but NOT the private key for the cert itself. Make sure you install the pfx (private key) into the cert store not the public key (.cer). You can also see if you have the private key by double clicking the cert in the cert store and on the general tab you should see a message saying as much.
Client Issue #3 - You put the cert in the wrong place. Probably best to place your cert in Certificates (Local Computer) \ Personal \ Certificates, rather than (current user). This will make the cert available to process accounts that are running your code and actually need access to it.
Client Issue #4 - Right mouse click the cert (in the store not a .cer file) --> All Tasks --> Manage Private Keys... and make sure the process account running your code has "Read" permission. A quick test of this (but not recommended for production use) is to add "Everyone" as read to see if this is your issue
I have a WCF web service running in IIS 7 using a self-signed certificate (it's a proof of concept to make sure this is the route I want to go). It's required to use SSL.
Is it possible to use the WCF Test Client to debug this service without needing a non-self-signed certificate?
When I try I get this error:
Error: Cannot obtain Metadata from
https:///Service1.svc
If this is a Windows (R) Communication
Foundation service to which you have
access, please check that you have
enabled metadata publishing at the
specified address. For help enabling
metadata publishing, please refer to
the MSDN documentation at
http://go.microsoft.com/fwlink/?LinkId=65455.WS-Metadata
Exchange Error URI:
https:///Service1.svc
Metadata contains a reference that
cannot be resolved:
'https:///Service1.svc'.
Could not establish trust relationship
for the SSL/TLS secure channel with
authority ''. The
underlying connection was closed:
Could not establish trust relationship
for the SSL/TLS secure channel. The
remote certificate is invalid
according to the validation
procedure.HTTP GET Error URI:
https:///Service1.svc
There was an error downloading
'https:///Service1.svc'.
The underlying connection was closed:
Could not establish trust relationship
for the SSL/TLS secure channel. The
remote certificate is invalid
according to the validation procedure.
EDIT: This question is specifically about using the WCF Test Client to test a web service already secured via SSL using a self-signed certificate. The server is already set up to accept any certificate provided, it's the WCF Test Client I don't see a way to do this for.
You can create a non self-signed certificate in development area and then use this certificate in IIS for applying the SSL. The steps are:
Create self-signed certificate
makecert -r -pe -n "CN=My Root Authority" -a sha1 -sky signature
-ss CA -sr CurrentUser
-cy authority
-sv CA.pvk CA.cer
Create a non self-signed certificate for SSL which signed by this root certificate and then create pfx-file from that
makecert -pe -n "CN=servername" -a sha1 -sky exchange
-eku 1.3.6.1.5.5.7.3.1 -ic CA.cer -iv CA.pvk
-sp "Microsoft RSA SChannel Cryptographic Provider"
-sy 12 -sv server.pvk server.cer
pvk2pfx -pvk server.pvk -spc server.cer -pfx server.pfx
now you just need to import the server.pfx into the IIS and setup the web site binding to use this certificate and also install the CA.cer in Local Computer \ Trusted Root Certification Authorities store in both server and client by doing this WCF client would work with the service through HTTPS without any problem.
you should be able to do this if you replace the WCF Test Client with WCFStorm Lite Edition. It's free and is quite a bit more flexible than MS's test client... for example, it'll let you specify a user name & password if you're doing username authentication.
The answer from this question helped in my case. Be sure to use exact machine name as certificate expects. For exampe machine/service.svc may not work, while machine.domain/service.svc - works.
To answer your question... here is how you force your WCF test client to accept a self-signed certificate...
using (ServiceReference1.Service1Client proxy = new ServiceReference1.Service1Client())
{
System.Net.Security.RemoteCertificateValidationCallback callBack = (sender, certificate, chain, sslPolicyErrors) => true;
ServicePointManager.ServerCertificateValidationCallback += callBack;
Console.WriteLine(proxy.GetData(35));
ServicePointManager.ServerCertificateValidationCallback -= callBack;
}
Yes it is possible.
Just download the generated WSDL from the service (https://localhost/Service1.svc?singleWsdl) and supply the path to this file when adding a service in the WCF Test Client.
You can supply your own method to validate the certificate.
Try this:
ServicePointManager.ServerCertificateValidationCallback +=
new System.Net.Security.RemoteCertificateValidationCallback(EasyCertCheck);
The call back:
bool EasyCertCheck(object sender, X509Certificate cert,
X509Chain chain, System.Net.Security.SslPolicyErrors error)
{
return true;
}