Since i was facing unrecognised algorithm crash, I did the patching as mentioned here:
http://erlang.org/pipermail/erlang-questions/2015-June/084870.html
The CRASH no longer appears but i do not get any APNS push notofications even after that. I have the sandbox environment at my end.
when i run on the ejabberd shell:
mod_mymodule:get_socket().
I get:
{error,{keyfile,{badmatch,{error,{asn1,{invalid_length,6}}}}}}
My certificate and private RSA key file worked fine for several months until this popped up.
The get_socket() method definition is:
get_socket()->
%%Options
Options = [{certfile, ?Cert}, {keyfile, ?Key}, {mode, binary}],
%%ssl connection
ssl:connect(?Address, ?Port, Options, infinity) .
FYI, I have macros declared like:
-define(Cert,"/opt/ejabberd-14.07/bin/MantuPush/cert.pem").
-define(Key,"/opt/ejabberd-14.07/bin/MantuPush/finalkey.pem").
Note: I havent used the CSR here, since examples do not state it mandatory(Guessing!).
What could be wrong?
What is the correct Certificate and Private key contents used with APNS?
Kindly help.
Thanks
This is an Erlang bug. Check out our Erlang pull request for quick hack and the discussion on Github: https://github.com/erlang/otp/pull/767
Here is the blog post explaining the issue: https://blog.process-one.net/apple-increasing-security-of-push-service-ahead-of-wwdc/
Related
Need Help!
I have been trying to reissue SSL in namecheap.com. I have already created multiple CSR using MacOS Keychain (Both from the Philippines, and from Japan) and through AWS. However, when I get to the Review & Submit part I keep getting an error (screenshot below). Thank you for any assistance with this, as I have tried numerous methods, and I still could not update the SSL.
I have gotten in touch with namecheap.com, and their response is
"... the certificate has this issue due to a bug from our side that is connected to .ink TLD. ..."
It seems that this is a bug in their system.
If anybody gets this error, you might want to connect with namecheap.com, to see if this bug is still not fixed.
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.
After following Mike Newswanger's writeup on Building a Secure PKI for Kubernetes (https://www.mikenewswanger.com/posts/2018/kubernetes-pki/), I run last step in the guide to request the certificate from my client machine:
cfssl gencert -config=request-profile.json -hostname=myhost.example.com -tls-remote-ca ca.pem -profile=default csr.json | cfssljson -bare myhost
The error is
{"code":7300,"message":"read tcp 192.168.122.106:37618-\u003e192.168.122.1:8888: read: connection reset by peer"}
Using tcpdump on the multirootca host, I see that cfssl is sending an HTTP request when multirootca is expecting HTTPS.
Nothing in the cfssl documentation that I've been able to find indicates how to force cfssl to use HTTPS on cert requests, and Mike's post indicates that it should just "work" at this point.
Has anyone had success using the latest release of cfssl or am I missing something trivial?
Note: I did have to modify the request-profile.json to remove the <:port> from the ca-server before I was able to get to this point
So after several trials/tribulations, the solution was pretty straightforward. In request-profile.json the URI needs to be https://<ca_server>:<port>.
This github issue https://github.com/cloudflare/cfssl/issues/898 helped point me in the right direction.
Also, if anyone else happens across this and are stuck, don't download the binaries from https://pkg.cfssl.org/ as they are severely outdated. Installing using Go is the best way to get the latest versions that actually work in the write-up mentioned in my Q (as well as the CloudFlare Blog).
I tried posting this on ask.openstack but it has been stuck in the moderator for 5 days now. I thought I'd try here.
I was trying to debug a Nova issue and wanted to decode the SSL / TLS packets being exchanged using Wireshark. Part of the changes I was making was setting Nova up to use SSL / TLS and I wanted to be sure that part of it I had set correctly. I eventually figure out my issues from the various log files but I'm somewhat assuming that being able to watch the network traffic may help in some very difficult cases.
The exchange uses TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 at one point. According to this security stackexchannge question, there is a "pre-master secret" or various other terms. I've wrestled with this before in a previous life doing IPSec. Usually you can set debug in the application and it will spew out the secret into the log file. I tried "debug = true" under Default in nova.conf and got lots of debug but no secret. There was two items that looked interesting that were reported as **** in the log: keystone_authtoken.memcache_secret_key and neutron.metadata_proxy_shared_secret. I wasn't sure if those were the secrets I was looking for or not. In this case, I'm looking at the nova-api traffic going to port 8774.
Also, since all of openstack is Python and uses the same "request" and "certifi" packages, it may be possible to generalize this to all of the openstack components.
nova --version report 9.1.1
I'm trying to retrieve data from an open data api. I have downloaded the certificate from the site and imported it into STRUST (SSL Client Anonymous).
Then I created a HTTP connection to external server in SM59. In the beginning it worked fine, until last week when the api changed its URL and so its DNS.
Of course it could no longer be reached by the current host. So I did above steps again for the new URL (changed everything accordingly like hostname etc. in SM59), but this time I receive following error:
SSL handshake with 'hostname:port' failed: SSSLERR_CONN_CLOSED (-10)#Remote
Peer has closed the network connection##SapSSLSessionStartNB()==SSSLERR_CONN_CLOSED##
Anyone has an idea on how to solve this?
On another forum someone helped me solve the problem. He pointed me out that the problem lies with SNI see: https://security.stackexchange.com/questions/101965/ssl3-error-when-requesting-connection-using-tls-1-2/102018#102018
https://en.wikipedia.org/wiki/Server_Name_Indication
To solve this problem you need to add following parameter: icm/HTTPS/client_sni_enabled and set it to TRUE on the DEFAULT profile. Afterwards you need to restart the application server in order to activate the effects of the parameter.
Link to the full question on SCN: https://answers.sap.com/questions/473015/sap-ssl-handshake-failed.html
EDIT:
I came across this error again later on, but this time it seemed that the error was caused because we used a certificate with TLS 1.2 which was not supported by our system. You can check this link: https://launchpad.support.sap.com/#/notes/510007 we implemented number 7 to fix this.