When using EppLib.net (and as per the Nominet instructions - http://registrars.nominet.uk/namespace/uk/registration-and-domain-management/registrar-systems/epp/testbed)
In order to verify the identity of the secure server you will need the 'Verisign Class 3 Public Primary Certification Authority' root certificate available free from www.verisign.com (the certificate is also distributed with most web browsers).
I am supplying the Verisign Class 3 PPCA Certs in .crt format (I can't export as a pfx) within the code (and have tried every cert installed on the server).
However each one fails with the error (when trying to negotiate the connection):
An existing connection was forcibly closed by the remote host.
I've confirmed that I can connect from the server to Nominet by running cURL
curl -v https://testbed-epp.nominet.org.uk:700
and that responds as I would expect - or at least without an error!
I have also tried to use the same cert that curl appears to be using without success.
Can anyone help with pointing me in the right direction with the SSL that I should be using or how to get hold of the correct certificate?
thanks in advance
For anyone having a similar issue, it wasn't a question of which SSL certificate to use, but to ensure the correct protocol was being used. Incidentally, I got it working initially using the curl-ca-bundle.crt provided with cURL.
This certificate, in combination with a change to the target .net framework for the EppLib.net project resolved my issue.
On cloning from Github the target was .net 4.0 and Nominet needs at least TLS1.1, which wasn't available in v4.
Therefore I also updated the target to 4.5.1 for the EppLib.net project and changed the SslProtocol from
SslProtocol.Tls to
SslProtocol.Tls12
Related
I am trying to add an advertiser link(paved.com) in my newsletter. Before adding to newsletter, I had to add that link to my custom domain, for that they (paved.com) had provided me with CNAME and it's value.
I add that to my DNS server, I am using aws's route53 as my dns server, so adding that was straightforward. But now, when I click on that link, it throws an unsupported protocol error i.e. ERR_SSL_VERSION_OR_CIPHER_MISMATCH
I have no clue how to debug this and I will really appreciate your time and help.
One thing I had tried was to issue a new certificate for the custom domain they had provided, but that also didn't work.
Commonly the error happens when the web browser and the web server don’t support a common SSL protocol version.
Did you check the tls version? try to force the tls version to 1.2 and have a try.
I basically tried to implement Netty's build in SSLHandler. I had no problems until i implemented the Client-Side SSL.
I tried everything out any neither of all tries actually checked an incoming certificate of a Server. I could basically connect me to invalid SSL Servers.
I only saw codes like these on the internet:
pipeline.addLast("ssl", SslContextBuilder.forClient().trustManager(InsecureTrustManagerFactory.INSTANCE).build().newHandler(channel.alloc(), UserConnection.SERVER_API_DOMAIN, UserConnection.SERVER_CONNECTION_PORT));
Any Ideas?
If you pass in .trustManager(null) , you get the system default which should check certificates based on the default root certs you have on your system.
To quote docs https://netty.io/4.1/api/io/netty/handler/ssl/SslContextBuilder.html#trustManager-java.lang.Iterable-
:
Trusted certificates for verifying the remote endpoint's certificate, null uses the system default
Of course, you could also leave out the .trustManager(...) call altogether, since the default is null
I'm getting errors, such as the one below, in my /var/log/mail.log file.
Apr 9 18:28:29 blueberry postfix/smtps/smtpd[13294]: warning: TLS library problem: error:14094415:SSL routines:ssl3_read_bytes:sslv3 alert certificate expired:../ssl/record/rec_layer_s3.c:1544:SSL alert number 45:
I'm 100% sure the certificates are valid since I'm using them on my websites, all of which couldn't be happier with them. Postfix was also happy previously, but since I renewed the certificates it's been spamming this when my Nextcloud server tries to (and can't) connect to the mail server, despite my mail client still working (although without rDNS as I didn't manage to get my provider to set it up).
I assume the blame is somewhere with Nextcloud - presumably the php handler for mail. Another thing that could be at fault that I tried to check is OpenSSL, but I have no idea how to replace its certificates with my own (generated by Acme.sh).
Both dovecot and postfix have in their config mentioned the correct path to my keys, hence the assumption above.
EDIT: Fixed it.
So, turns out, when I updated my certificate locations when I changed the method of acquiring them (certbot vs acme.sh), I got a typo in one of the filenames. /etc/dovecot/conf.d/10-ssl.conf was correct and so was /etc/postfix/main.cf, but /etc/postfix/vmail_ssl.map had a typo which I didn't see previously - and so was throwing a certificate error.
We're struggling to get IBM MQ to work across SSL.
We've been provided with the certificate chain for the remote host and installed into the Windows Certificate Store (Local Machine). These all look valid.
We're using the following connection properties:
connectionProperties.Add(MQC.SSL_PEER_NAME_PROPERTY, "other-server.com");
connectionProperties.Add(MQC.SSL_CIPHER_SUITE_PROPERTY, "TLS_RSA_WITH_AES_256_CBC_SHA256"); connectionProperties.Add(MQC.SSL_CIPHER_SPEC_PROPERTY, "TLS_RSA_WITH_AES_256_CBC_SHA256");
connectionProperties.Add(MQC.SSL_CERT_STORE_PROPERTY, "*SYSTEM");
connectionProperties.Add("CertificateLabel", "ibmwebspheremqmywindowsusernamewithoutdomain");
MQEnvironment.SSLCertRevocationCheck = true;
We've established that the "CertificateLabel" is the "Friendly name" in Windows parlance.
We've proven unencrypted communication and network-level configuration.
We're using 8.0.0.7 client.
These are the issues we've come across:
All secure communications fail with a 2538 error. (MQRC_HOST_NOT_AVAILABLE, https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_7.5.0/com.ibm.mq.tro.doc/q045380_.htm)
No success setting the Friendly Name to ibmwebspheremq and ibmwebspheremqmywindowsusername#domain and ibmwebspheremqmywindowsusernamewithoutdomain
General questions:
Are we correct in assuming that we can install generated certificates exclusively in the Windows Certificate Store?
Is the 2538 error even related to SSL communications? It feels like a network error, though there is that final point in the referenced error documentation.
Is there anywhere we can look for more informative error information? eg. relating to the SSL trust chain to see if there is an issue there?
The issue was the following line:
connectionProperties.Add(MQC.SSL_PEER_NAME_PROPERTY, "otherserver.com");
Turns out that:
It needs it in a canonical format, so DN=, etc.
You don't even need that line
Though we did learn a few things along the way:
The line:
connectionProperties.Add("CertificateLabel", "ibmwebspheremqmyusername");
Is the string ibmwebspheremq plus your Windows username (without your domain) and the label should be set on the Friendly name of your client machine's outgoing certificate NOT including the username.
The various folders inside your Windows certificate store are significant. The intermediate CAs should be correctly filed.
I'm running a site and several sub domains on ColdFuson 10 Standard, we have just upgraded from ColdFusion 9 where everything was working fine.
The sites have a wildcard ssl certificate installed so all the sub domains are secured. I'm making http calls between the sites but getting the I/O Exception: peer not authenticated error.
Charset [empty string]
ErrorDetail I/O Exception: peer not authenticated
Filecontent Connection Failure
Header [empty string]
Mimetype Unable to determine MIME type of file.
Responseheader struct [empty]
Statuscode Connection Failure. Status code unavailable.
Text YES
I've installed the certificate in the correct key store and verified it's there using keytool -listand restarted, but still get the authentication error.
I know this is a common problem and is usually fixed by installing the certificate and there are workarounds for ColdFusion Enterprise but I'm struggling to get this working on Standard. Any suggestions?
After many days of investigation I came across this blog post which leads to bug report #3598342.
It turns out to be an issue on Windows 2012 servers running IIS 8. There is an option on the site binding to 'Require Server Name Indication' or 'SNI'. Turning this option off allows cfhttp to connect via https.
It turns out this is an issue with the HttpClient library and has been fixed in builds 288845, 288846 and 290605. Which doesn't really help as the last update 13 only gives me build 287689.
This could be an issue I have run across where I had to import the secure server certificate into coldfusion before it would allow me to connect.
http://helpx.adobe.com/coldfusion/kb/import-certificates-certificate-stores-coldfusion.html
Import Certificate for ColdFusion10
Hope that helps. I know it helped me!