Just a quickie.
I am not sure how to approach securing a self hosted WCF service with an SSL certificate. When buying an SSL certificate, I need to do a certificate request based on the FQDN.
Using a self hosted WCF service,
How do I generate a certificate request for a self hsoted WCF service?
How do I implement the F.Q.D.N. for a certificate for a self hosted service? The self hsoted service is accessed on a dynamic DNS name and a port.
Should I just generate a self signed certificate and use that?
Regards
The following link demonstrates the process and enumerates the steps for establishing a certificate signing request.
http://technet.microsoft.com/en-us/library/ff625722(v=ws.10).aspx
We specify the following for our self-hosted WCF SSL services:
On the Subject tab:
1. In the Subject name area under Type, click Common Name.
2. In the Subject name area under Value, enter the fully qualified domain name, and then click Add.
3. In the Alternative name area under Type, click DNS.
4. In the Alternative name area under Value, enter the fully qualified domain name, and then click Add.
On the Extensions tab:
1. Click the Key usage arrow. In the Available options list, click Digital signature, and then click Add. Click Key encipherment, and then click Add.
2. Click the Extended Key Usage (application policies) arrow. In the Available options list, click Server Authentication and Client Authentication, and then click Add.
The SSL certificate has two parts to it that you need to know about. The first is the host. This is sent back to the client, so they can verify that the SSL certificate is for what you THINK you were connecting to.
So your host name NEEDS to match the address you are using to connect to the WCF service.
The second part is the signature. This is to verify the SSL certificate has not been changed since it was issued. Think of it as a Counter Signature on your rental agreement.
Now what a Self Signed certificate means...well its exactly what it says on the tin. Your computer signed it. Where as normally you would pay a Certificate Authority to sign it (think of it like getting a Judge to Counter Sign your rental agreement).
So the down side of the Self Signed cert is that no one trusts it, and for good reason.
For 99% of cases, your self signed cert is not going to be trusted by anyone.
Related
I'm looking at hardening LDAP on my domain controller (DC). To do this I need to import a security certificate to the DC.
I don't want to self sign as I've been told it is not best practice and the service I wish to integrate with LDAPS (Mimecast) does not recommend self signing.
I've created my certificate request, based upon the domain's fqdn. e.g. mydomain.local
What I'm not sure about now is where I can get a certificate based on that request.
I'm familiar with SSL for HTTPS. That process makes sense to me, the certification authority checks that I own the domain and provides a certificate that I can then install on my web server.
Will 3rd party SSL providers let me configure a certificate with the common name "mydomain.local"?
Or am I looking in completely the wrong area?
Many thanks in advance for any help that provided.
The type of certificate is exactly the same type of certificate as you would get for securing a website, yes. However, the domain name must be a valid internet domain (not .local)
There is a good walk-through here for Using Let's Encrtypt for Active Directory Domain Controller Certificates, including all the caveats you need to be aware of.
I am developing browser extension, that sends some data from currently browsed page to my backend server. User is aware of it, it is intended.
I don't want to cause any user-data exposure, when the user is e.g. on unsecured wifi. So I just want to ensure, the data and the url goes over the net encrypted and only my backend will see them.
Do I understand correctly, that any SSL certificate, even free one from StartSSL will do the trick?
What other side effects with free SSL certificate should I consider?
- will the user's http-client trust such a certificate?
Thanks.
The SSL certificate will do the trick as long as it can be validated. That means that the root certificate of the certificate chain needs to be within the trusted certificate store of the browser.
Furthermore, the certificate will have to be for the right address (URL), must not be revoked, CRL's and OCSP must be configured correctly etc. etc. In other words, the usual steps required to have your web-service certificate validated must be met.
I have a simple question (maybe stupid) and i didn't find any clear answer to it. If i get a certificate from a trusted signing company (like verisign...) for one of my server (web for instance), i'll have private an public keys. With this certificate can i set up my own intermediate CA and sign cert request and the be trusted by every one (i know that's shouldn't be..)? My real question is : what will prevent me for issuing certificate and how the company can garanty that nobody does ??
Thanking in advance!
The certificate issued for your web site is suitable for SSL/TLS and is not suitable for issuing other certificates (Key Usage field is different). Consequently while you technically can generate another certificate using yours as a CA, such generated certificate won't be trusted by properly implemented and configured validators (those that check Key Usage).
You are not paying verisign or other certificate organisation for the certificate publishing but for the certificate validation, this meens that they have web services that respond if your certificate is valid or not, if it is still active and not expired and your contact information as requested.
Unfortunatly this is something you have to live with it and pay them if you really need ssl over your site.
I have used a homemade certificate for my lan server and when i visit this https site a big red warning notifies me that this site is malicious and it has not a valid certificate. This doesn't bother me but I am sure that all of my clients would have freeked out if they see such a bold warning popping up to their browser.
what can you do? it's a companies' world
Currently I am having a problem connecting to the server due to the following issue:
When I tried to connect to the server, it returned an error: MQRC_SSL_INITIALIZATION_ERROR
Upon closer analysis via WireShark, I found that the Client is attempting to connect to the server using SSL v2, while the server can only accept SSL V3, thus rejecting the connection.
I checked through the document, but am not able to find any information on
what SSL version the .Net client supports.
I would like to check whether the SSL version is controlled from the .Net MQ
client, and if so, how can we configure to make it connect via SSL v3?
Thanks.
I'm not sure I agree with your conclusion since WMQ has supported SSL V3.0 and TLS V1.0 since at least V6.0 and possibly earlier. This is more likely a mismatch of configurations between the client and server. The procedure I recommend to resolve SSL/TLS issues is as follows:
My method for debugging SSL connections on WMQ is to progress through the following sequence making sure each step works before advancing to the next:
Get the channel running without SSL. This validates that the channel names are spelled correctly, that a network route exists between the endpoints, that the QMgr's listener is running and that the client points to the right port. You'd be surprised how many times someone mis-keys a port or channel name.
Get the channel running with the SVRCONN definition set to SSLCAUTH(OPTIONAL). This performs an anonymous SSL connection similar to what your browser does. The QMgr presents a certificate to the client but the client is not obligated to send one back. This validates that the QMgr can find its certificate and that the client can find its trust store and properly validates the QMgr's cert. (Note: the QMgr will always request the client cert and the client will always send it if one is present. To perform this test, use a copy of the client's keystore that has the signer cert(s) but not the application's personal cert. Copy the keystore and delete the personal cert from the copy. Do NOT delete the original!)
Set the SVRCONN channel to SSLCAUTH(REQUIRED). This now requires the client to find its keystore (in the last step it required only its trust store) and to be able to find its certificate. It also requires the QMgr to be able to validate the client's cert.
Set up SSLPEER or CHLAUTH mapping rules to narrow the population of validated certificates that will be accepted on the channel.
The difference between steps #2 and #3 helps to isolate the problem by testing the SSL credential exchange in only one direction at a time. This allows you to identify whether the problem exists in the personal cert or the public cert and on which side of the channel. Nearly all problems are sorted out in these two steps.
UPDATE
Notes to respond to questions. There are two types of certificate used with SSL/TLS. The personal certificate contains the private key and is the one that doesn't get passed around. The public certificate is the one that contains the public key and can be given out freely. The private key is held in a keystore. The public keys (usually these are the CA's root and intermediate certs) are stored in a trust store. In some cases, these are separate files. For example, in Java and JMS the JSSE provider looks in the environment for variables that point to the keystore and to the trust store. It is possible in Java and JMS that the keystore and trust store variables point to the same file.
In the case of WebSphere MQ servers and clients other than Java, the keystore and trust store are combined into a single location. Often referred to as a kdb file, it is actually a CMS key database comprised of several files of which one is the KDB. In this case "keystore" is actually shorthand for a combined keystore and trust store. For the .Net client, set the keystore location and other SSL properties in the MQEnviornment.
In the SSL/TLS handshake, the server always sends its public certificate in response to a connections request. The client then must validate that certificate by first checking the signature and validity date, then looking in its trust store for the thing that signed the certificate. If the thing that signed the certificate is an intermediate signer cert (it has itself been signed by something) then the search continues up the signer cert chain until the root cert is reached. Assuming that the server is authenticated, the same procedure is applied in reverse by having the client present a cert and the server validating it.
When the process fails in Step #2 we can debug using knowledge of the process above. The QMgr must first find its cert in its keystore and present it to the client. If the QMgr cannot find its cert, the result is errors in the AMQERR01.LOG file stating this. Always look on the QMgr side first when things die in Step #2!
If the QMgr does find its cert then the next step is that client must be able to find its trust store and then within that trust store must find the necessary signer cert chain. If this fails, there should be errors on the client side to indicate that. For example, a common error when setting the client environment is to specify the entire file name, including the .kdb extension. When this happens the QMgr looks for [keystorename].kdb.kdb which doesn't exist. Another common error is that the personal certificate exists in the keystore but with the wrong label. Non-Java WMQ clients look for the certificate by label name constructed from the literal string ibmwebspheremq followed by the user ID in lower case. For example, if my user ID is TRob then my certificate label would be ibmwebspheremqtrob. Note that this is the certificate's label in the keystore and NOT the certificates Common Name or other field in the Distinguished Name.
Depending on the type of client in use, these may be in the Windows error log, local MQ error logs or other location. If you can't find client-side errors, WMQ tracing is also an option.
I need to implement a SSL certificate for a website, I've got three questions after some research.
1) I believe i need to buy a SSL certificate and ask my host to install it. My question is do you need to alter any code for the website for the certificate?
2) Before I buy the certificate, the website is going to be built for a couple of month at least. I'm just wondering is there a developing SSL certificate I can use for the developing environment?
3) Or do I have to use self assigned certificate? If so are there any good tutorials on how to create a SSL self assigned certificate on a local machine (wamp) and a developing url site?
Thank you very much.
Sam :)
1) No, you do not need to alter any code on your website at all in order to use an installed SSL certificate. It is as simple as prefixing your desired destination link with the HTTPS: protocol specification instead of the typical HTTP: protocol. However, if you want to determine if your site visitor is using an encrypted page before they do something, such as submit a web form with potentially sensitive data, then depending on what you are developing your site in, you will need to detect if the current page request has been sent over HTTP or HTTPS, then if it is an HTTP requested page, you probably want to redirect the page request to the HTTPS version before proceeding.
2) Other than creating your own "self signed" certificate (more on this in #3), no your only option for a publicly valid SSL certificate is to obtain one from a publicly recognized Certificate Authority (CA). Long story short, a certificate of the same key length using the same encryption standard supported by your server and visitor's web browser, is no stronger or weaker regardless of vendor for purposes of encryption. So you can simply shop by price for your SSL certs. I have no affiliation with GoDaddy, but have been using them for years for public SSL certificates.
3) You certainly can create your own self signed certificate. The methods for doing this vary based on your host server and version. The limitation to a self signed certificate, is that if you go to share this with anyone, you get that warning message from your browser that the certificate is not published from a verifiable source. In most current browsers, it looks like a big scary message that something is wrong and they attempt to warn your user away from doing this. However, of course, there is certainly nothing wrong with using a self signed certificate. This is obviously true for your own development uses. Even a self signed certificate of the same key length and encryption method is as cryptographically secure as a commercially provided certificate. If you want to use a self signed certificate, just search for instruction for doing that for your server OS and version for details. Once it is installed, you will get the warning from your browser when you try to browse to a page over HTTPS. Your browser should show you an option to permanently remember and accept your self signed certificate, after which you will no longer see that warning while that certificate remains installed and valid.