I try to send a message to MSMQ using WCF. I want to use Transport security and sign messages. However, when I set clientcertificate credentials and try to send message, an error is being thrown: "An error occurred while sending to the queue: The user certificate is invalid. (-1072824276, 0xc00e002c)". Certificate is stored in LocalMachine\My location and has read only access set for ASPNET process.
Here are two common reasons a certificate is considered "invalid":
You don't have the private key associated with the certificate. If you don't have the private key, you need to re-install the cert with the private key, or get a new cert for which you do have the private key.
The certificate is issued by a certificate authority that is not trusted by your computer. If this is the problem, you need to install the issuing authority's certificate into your "Trusted Root Certificate Authority" store (there are security risks involved with doing this so make sure you read the pop-up warning that will come up when trying to do this).
View the certificate in the CertMgr.msc to see if its one of these issues. (Start > Run > CertMgr.msc > Personal > Certificates).
Related
I want to use WinRM with https transport. I've bought a Comodo certificate (the error states I cannot use a self-signed certificate) with the Subject matching my FQDN (Full computer name in System) of my Windows 10 computer (not domain joined):
CN = my.domain.net
OU = PositiveSSL
OU = Domain Control Validated
When trying to create a https listener with the following command:
WinRm quickconfig -transport:https
I get the error 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.
I've installed (doubleclick the *.crt file) the certificate in several stores (local machine / personal and Trusted Root Certification Authorities) but WinRM fails to create the https listener. The http listener is working OK.
Some extra info: When using certreq to try to install the *.cer certificate, I get the error:
Element not found. 0x80070490 (WIN32: 1168 ERROR_NOT_FOUND)
How do I get WinRM working with https?
Here is how I solved this issue:
create a SSL CSR using DigiCert Certificate Utility for Windows from digicert.com
use the generate CSR to request a certificate. I used versio.nl but I'll guess there are a lot of CA's out there
Install the certificate by double clicking it
go to the certificate manager for user
rightclick the certificate (it should me in the personal store) and export it
- follow the wizard and be sure to export the private key
install the newly exported certificate (mark the key as exportable and include all extended properties) in the local computer certificate store
Open an console (cmd) with administrator privilidges and type:
winrm create winrm/config/Listener?Address=*+Transport=HTTPS
#{Hostname="server.fqdn";CertificateThumbprint="YOURCERTIFICATETHUMPPRINT"}
This worked for me. Some things to check if it is not working:
is the certificate still valid (check the date range)
check if the certificate property 'Subject" has a CN value with the FQDN of your computer
check if the listener is installed (winrm e winrm/config/listener)
I took me a lot of hours to figure this out. I hope it will help some of you out there.
I also experienced this issue - the answer from RHAD was partially helpful, but I needed to use an entirely internally generated CA.
The problem was caused by the Key algorithm I had chosen. Using the same configuration, only changing the key it works:
Failed key: elliptic curve cryptography with the brainpoolP512t1 curve (in the certificate this showed as: Public Key Algorithm: id-ecPublicKey / ASN1 OID: brainpoolP512t1 )
Successful key: an RSA key: (in the certificate: RSA Public-Key: (4096 bit))
Hopefully this helps others with similar issues.
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 trying to run a test of the SAML2 SSO using WSO2 Identity Server 4.0.0 M7 but am not successful.
I tried to use the 3.2.3 binary but ran into the bug about long hostnames and the identity.xml file (http://stackoverflow.com/questions/9600392/unable-to-configure-wso2-identity-server-for-openid).
These are the examples I'm using:
http://sureshatt.blogspot.com/2012/08/saml20-sso-with-wso2-identity-server.html
http://wso2.org/library/articles/2010/07/saml2-web-browser-based-sso-wso2-identity-server
I've stood up a new Tomcat7 server and configured it for HTTPS, which works cleanly in the browser. The certs are signed by our trusted enterprise CA and both the private key and chain certs are installed.
Same for the WSO2-IS host which has a new wso2carbon.jks with the private key signed by the same CA. I've exported the host cert from wso2carbon.jks and imported same into the client-truststore.jks. The trusted CA-signed certs are also in client-truststore.jks (at this point just to be sure). They are also in wso2carbon.jks (used to trust the CA reply).
I've changed the HostName and MgtHostName in carbon.xml to match the CN in the private key; the Carbon console comes up cleanly with no SSL issues and I can log in using the 'admin' user with no problem. From there I've updated the SSO configuration using the above example links as guides. That works with no errors.
When I go to each site (e.g., saml2.demo, avis.com, etc.) they redirect perfectly to IS to authenticate. However when I log in I get the error in the log "Issuer details are not valid. Issuer details should be registered in advance". And then I'm stuck.
What have I missed?
Have you done the 5th step of the topic 2 Configuring the WSO2 Identity Server ? Please check the value you've registered as the Issuer is as same as the one that comes in the SAML Authentication Request message.
I am testing a web service with an external partner using 2 way SSL under IIS 7.5. I am requiring SSL, requiring a client cert, and using one to one mapping to authenticate to a domain account. I have configured everything and it works fine on our network (I am able to provide a client cert, get authenticated and invoke the service from browser and test harness).
From outside of our network (in most cases, see below), I am getting a 403.7 error. I have gone through the machine level certificate store and made sure the certificates and CAs are trusted.
Here's the weird thing. I obtained a Type I cert to test from home (and got 403.7 like our intended partner is). So I setup Fiddler to debug SSL and send my certificate, and this works for some reason. I setup a test harness to pass the exact same certificate, and got 403.7. I test in my browser (IE 9), don't get a prompt for a client cert, and get 403.7.
Any help appreciated.
Bill
Last time I checked, IIS was using re-negotiation (by default) to get the client certificate: there is a first handshake where the server doesn't request a client certificate, followed by another handshake (encrypted this time) where the server requests the certificate (via a TLS CertificateRequest message). This will prevent you from seeing anything from Wireshark, unless you configure it to use the server's private key and decipher the traffic (note that this only works with some cipher suites).
One way to see the client-certificate negotiation is to configure IIS to use initial client certificate negotiation, using netsh and clientcertnegotiation=true (which is about initial negotiation). At least the CertificateRequest and the certificate will be sent in clear during the handshake, so you should be able to see this with Wireshark.
If the client isn't sending a certificate to the server as a response to the CertificateRequest, you'll still see an empty Certificate message from the client.
If you don't export the private key with the certificate to use with Fiddler or whichever other client, there is no chance that it will be able to use the certificate. It may at best try to send the certificate, but the handshake will fail (since the CertificateVerify message needs to be signed by the client's private key).
I guess you may encounter a problem whereby:
not presenting a certificate is accepted by the server (it's effectively optional),
presenting an invalid certificate makes it fail and causes this 403.7 status code (many servers and SSL/TLS stacks would implement this as a fatal error, but TLS specification doesn't say that unsupported_certificate, certificate_revoked, certificate_expired, certificate_unknown should be fatal, so this is at the server's discretion).
Are you using the same physical machine to test both the in-network and external-network connections? If not, are you sure that the external-network client has the private key accessible?
I have not configured Fiddler client authentication before. Does it read the client certificate and key from the standard certificate stores? Does it read directly from a PKCS12?
One other thing that may be helpful is inspecting the TLS handshake in WireShark. Specifically, check out the Server's "Certificate Request" message, as the data here clues the client (IE9) which client certificates it should display in the prompt. Compare this for the internal and external connections.
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..