I have an IBM HTTP Server and Server [X] ,
I need to create secure connection [SSL] :
by creating KDB file : ibmhttpserverkey.kdb in IBM HTTP Server using iKeyman utility and importing Server[X]'s certificates [cert.PEM] or [cert.der] in ibmhttpserverkey.kdb
it's do-able or not?
I have tried a lot and every time it returns "Error Handshake, no certificate found" even if i installed it using certification manager!
You should be able to import certificates from other key file types such as a p12 database or another kdb. After doing the import check the personal certificates using IKEYMAN to see if the certificate is there. If you then see the "Error Handshake, no certificate found" in the IHS error log it may be you have not specified the certificate to be the default. Also check the VirtualHost entry for port 443 (or whatever ssl port is used) and see if an SSLServerCert directive is defined. This directive can be used to point at a label that identifies the needed certificate. The no certificate found message means that IHS opened the kdb defined by the keyfile directive and could not find either a default certificate or one that is specified using the SSLServerCert directive.
Guide to setting up SSL within IHS:
http://www-01.ibm.com/support/docview.wss?uid=swg21179559
Related
I am using CometD library for nodejs on server side using the https://www.npmjs.com/package/cometd-nodejs-client. The server (Genesys) that I am trying to connect uses SSL, due to SSL cert I am getting SSL error when connecting to the server using CometD. My question is that is there a way to pass the ca cert to CometD library (https://www.npmjs.com/package/cometd)?
The XMLHttpRequest provided by the CometD library exposes a _config() function that returns a configuration object that is passed to Node's http.request(...), allowing you to configure TLS if so you need.
You can refer to this test case:
https://github.com/cometd/cometd-nodejs-client/blob/1.3.0/test/https.js#L53
I am also seeing a similar issue when using CometD and CometD Client packages to connect to Genesys.
I have a nodejs server that adds all the /meta/handshake, /meta/connect, /meta/disconnect... listeners. When I try to trigger the /meta/handshake I seeing SSL self signed certificate in certificate chain error. As a solution, I tried to install the ssl certificates on my server and tried to connect to Genesys but I still see the same self signed certificate error.
Is there a way to configure the listeners with rejectUnauthorized: false?
Only some (not all) users are receiving ERR_SSL_PROTOCOL_ERROR in Chrome when attempting to visit my express site. I am not receiving this error, so it is proving a pain to debug.
I am creating a https server using a PFX file I downloaded from my provider (1&1):
var options = {
pfx: fs.readFileSync('./mysite_private_key.pfx'),
passphrase: 'MYPASSPHRASE',
};
https.createServer(options, app).listen(443);
https://whatsmychaincert.com tells me that the chain is correct but complains about the handshake:
[mysite] has the correct chain.
[mysite]: TLS handshake error:
error:14077438:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert
internal error SSL Labs might be able to tell you what went wrong
I've googled this with no success, does anyone know what the problem could be? Ty.
In the end I ditched 1&1 and used GoDaddy's CA service and the problem went away.
A possible source of failed handshake could be the lack of an intermediate certificate, ca option of tls.createSecureContext. It should by public on your provider's website.
Hope this helps.
nowadays , when our server (e.g. 1&1) is securely configured , only tls v1.2 and tls v1.3 are supported ..
so how you debug this:
scan your site with SSL Labs Test too see which ciphers are supported , or alternately see in our nginx/apache config
tail -f the server logs , especially the catchall/other_vhosts log files,since ssl protocol errors might be in the site logs and the generic catchall log when the server cannot decide on the name
try to update the users chrome to support at least tls 1.2
chrome has the some command line switches to change its cipher behaviour:
--ssl-version-max Specifies the maximum SSL/TLS version ("tls1.2" or "tls1.3"). ↪
--ssl-version-min Specifies the minimum SSL/TLS version ("tls1", "tls1.1", "tls1.2", or "tls1.3"). ↪
DANGER ZONE:
as last resort you could try to accept legacy ciphers in your nginx-config ( ssl_ciphers directive) like socat OR (very last resort) socat23 to check which version your clients support,
remember to disable everything below tls v1.2 in production environment
Any time I attempt to send mail from my mail client (In this case, thunderbird), it comes up with an arbitrary error for why it couldn't send the email (The error doesn't matter, as it simply is telling me that the connection got dropped). When I run tail -f /var/log/maillog I see:
smtp disconnected reason=ca-failure
I can't seem to find anywhere online talking about this and how to fix it.
I've attempted to use several different matching keys and certificates, locally sourced (openssl) and from letsencrypt. OpenSMTP accepts all of these no problem. I have also went as far as to specify the root CA certificate for letsencrypt with their certificates.
Did you define the mail hostname for the OpenSMTPD server?
This file is supposed to be found in /etc/mail/mailname, and it should match the pkiname thats in the smtpd.conf file "pki 'hostname' cert /etc/letsencrypt/live/www.domain.com/cert.pem"
I spent an hour or two fighting with this.
This is defined in the manual:
pki pkiname cert certfile
Associate certificate file certfile with host pkiname, and use that file to prove the identity of the mail server to clients. pkiname
is the server's name, derived from the default hostname or set using
either /etc/mail/mailname or using the hostname directive. If a
fallback certificate or SNI is wanted, the ‘*’ wildcard may be used as
pkiname.
A certificate chain may be created by appending one or many certificates, including a Certificate Authority certificate, to certfile. The creation of certificates is documented in starttls(8).
I am using the following web2py slice in attempt to use https for a service worker function in a page.
http://www.web2pyslices.com/slice/show/1507/generate-ssl-self-signed-certificate-and-key-enable-https-encryption-in-web2py
I have tried opening web2py with the following line (with and without [-i IP and -p PORT]):
python web2py.py -c myPath/ssl_certificate.crt -k myPath/ssl_self_signed.key -i 127.0.0.1 -p 8000
but https is declared 'not private' and is crossed out. Because of this, I am getting a SSL certificate error when the registration of the service worker is attempted.
Please indicate what is going wrong or whether more information is needed
You mention "https is declared 'not private' and is crossed out". This has to do with browsers disliking not trusted (self-signed) certificates, because that's what trust is all about. If any hacker could just make up a certificate and the https client wouldn't respond with at least a frown, you could still be hacked or sniffed without noticing. Since you don't mention any other error, I assume you get otherwise valid results from the web2py server?
If so, you have setup your self-signed certificate well. If you don't get any valid html response (outside your browsers complaint, of course), you still have an issue with the setup.
If your service worker won't accept the certificate, what you can do (in a test environment at least) is import the self-signed certificate into the machine or service worker certificate repository. The process differs per OS and version.
Hope this helps. If it doesn't, please provide more detail.
The best way to use ssl with web2py is use of the deployment recipes with prodution-grade webservers like apache, nginx or Lighttpd.
Any of the mentioned scripts create a self-signed certificate, and then, you have to fix the generated server config files to a real certificate.
You can buy a real ssl certificate from any of many resellers or get for free from Let's Encript, if you have a real IP, like in a VPS or server.
A simple way to fix the config files is create a simbolic link from the real certificate to the one mentioned in the server config file.
To just test your service worker in your machine or a internal test server, just use a non-ssl port, or like Remco sugested, import the self-signed certificate to client environment.
I am trying to configure an IIS website to require SSL client certificates. The website is set up in both IIS 6 and 7, though I am more interested in making it work for 7. I set the require client certificates property in IIS and it works fine when accessing the site through a web browser, but a Java-based client is having trouble accessing it.
I believe the problem is that IIS does not request a client certificate during the initial SSL handshake. Instead it negotiates a normal SSL connection, checks to see if the resource requires client certificates, and if it does it then initiates a new SSL handshake that requests a client certificate. IIS does this so support sites that only require the client certificates for certain resources. Even when the requirement is specified for the entire website, IIS still initiates two SSL handshakes. I want to force IIS to request the client certificate on the first SSL handshake, which will hopefully get things working for the client. (The client is developed by an external partner and I have virtually no knowledge of how it is set up and no access to its source code)
Has anyone dealt with this problem in IIS before?
Here's how I did this, on IIS 7.5:
Run the following in an admin command prompt: netsh http show sslcert
Save the output in a text file. Will look something like this:
IP:port : 0.0.0.0:443
Certificate Hash : [a hash value]
Application ID : {[a GUID]}
Certificate Store Name : MY
Verify Client Certificate Revocation : Enabled
Verify Revocation Using Cached Client Certificate Only : Disabled
Usage Check : Enabled
Revocation Freshness Time : 0
URL Retrieval Timeout : 0
Ctl Identifier : (null)
Ctl Store Name : (null)
DS Mapper Usage : Disabled
Negotiate Client Certificate : Disabled
Create a batch file using that info:
netsh http show sslcert
netsh http delete sslcert ipport=0.0.0.0:443
netsh http add sslcert ipport=0.0.0.0:443 certhash=[your cert hash from above] appid={[your GUID from above]} certstorename=MY verifyclientcertrevocation=enable VerifyRevocationWithCachedClientCertOnly=disable UsageCheck=Enable clientcertnegotiation=enable
netsh http show sslcert
(Yes, you have to delete and re-add; you can't just alter clientcertnegotiation in-place. That's why it's important to save the hash and GUID, so it knows what to re-add.)
Run that batch file, check for any errors, done.
Keep in mind that this setting is applied per-certificate, not per-server. So if you use multiple certs, or change/update your cert, you will have to do this again.
It took me a while to find this metabase setting. We were having this same problem with our client using the new certicom libraries. Since the discovery of the MITM attack arround SSL Renegotiation, the answer in alot of circles has been to hangup on renegotitation requests.
running the following cmd from \inetpub\adminscripts will force IIS to always request a client certificate.
For IIS 6:
cscript adsutil.vbs set \w3svc\siteID\SSLAlwaysNegoClientCert True
(So for the default website, cscript adsutil.vbs set \w3svc\1\SSLAlwaysNegoClientCert True)
Keep in mind that some clients Internet Explorer prompt for client certificates when it recieves that packet wether the client certificate is needed or not.
For IIS 7:
Save the following text to a file called "Enable_SSL_Renegotiate_Workaround.js"
var vdirObj=GetObject("IIS://localhost/W3svc/1");
// replace 1 on this line with the number of the web site you wish to configure
WScript.Echo("Value of SSLAlwaysNegoClientCert Before: " + vdirObj.SSLAlwaysNegoClientCert);
vdirObj.Put("SSLAlwaysNegoClientCert", true);
vdirObj.SetInfo();
WScript.Echo("Value of SSLAlwaysNegoClientCert After: " + vdirObj.SSLAlwaysNegoClientCert);
Run the following command from an elevated / administrator command prompt:
cscript.exe enable_ssl_renegotiate_workaround.js
(Jacked from the KB article for 977377)