I am facing an issue while sending request to server for push notification. While trying to connect to apple server we are getting the following response,
ApnsPHP[15748]: INFO: Trying ssl://gateway.sandbox.push.apple.com:2195... Tue, 15 Jan 2013 08:20:28 +0100 ApnsPHP[15748]: ERROR: Unable to connect to 'ssl://gateway.sandbox.push.apple.com:2195': Permission denied (13)
We checked the server settings and the server is not blocking any out going requests. We created the p12 certificate as per the guidelines by apple, and we are converting it to .pem by executing following shell command in the server.
openssl pkcs12 -in HSPushNopassword.p12 -out HSPushNopassword.pem -nodes -clcerts
And the same code and certificate is working fine in another server.
Please let me know why we are getting this error? Thanks,
There is a better solution than disabling SELinux completely. The problem is that on most SELinux systems (as RedHat, which I am using) HTTPD is not allowed to create network connections.
You can use this command to enable it:
setsebool -P httpd_can_network_connect=1
-P for permanent setting.
I hope it helps, though this thread is accepted
I sorted it out. Yes, the problem was the server, but it was likely due to when they had root and reloaded things. In a nutshell, there is a very restrictive security system called 'selinux'. So I disabled that, and set the config so it stays off after reboot. And the push notification is working fine now.
Related
My app has 1:1 video calling feature and for that I set up my own turnserver. The turnserver was running perfectly till yesterday. When I try to call from app, turnserver rejects. I tried turnserver url from browser, it shows something like this,
Immediately, I logged collidermain, it shows
root#<machine_name>:~# <timestamp> Starting collider: tls = true, port = 8443, room-server=https://<mydomain>.com
<timestamp> http: TLS handshake error from 182.160.105.186:43243: remote error: tls: unknown certificate
And this kept showing up everytime, my app try to connect with turnserver.
Thought, ssl certificates got something to do with it, replaced ssl certificates, tried re-installing collidermain, restarting google-cloud-sdk, turnserver, collidermain. Still no luck.
Got two similar questions on stakoverflow.
WebSocket open error: WebSocket error, This is not chrome bug, because I got other two turnserver running perfectly fine at the time I am writing this and server health is pretty good
Websocket open error, websocket register error This is not working too. I re-installed collider. No luck
My question is, what is the root cause of this error and how to fix it?
System spces:
OS: Ubuntu 20.04
AppRTC code running with Google-cloud-sdk, version: 330.0.0
Turnserver version: 4.4.3
Signalling server: collidermain
Certificate issued with let's encrypt certbot
It's solved! Here's what happend.
I copied the certificates issued by certbot into another directory /cert/
and in turnserver.conf file, I pointed certificate path to /cert/ directory. So it worked fine for a while. Certbot certificates are valid for 3 months and it's renew automatically when validity expires. So, certbot renewed certificates and put it into /etc/letsencrypt/live/:domain_name/. turnserver.conf still pointing to outdated certificates resides in /cert/ directory. That's why when I try to join a room, turnserver using outdated certificates and shows TLS handshake error
So, I just changed certificate path from /cert/ to /etc/letsencrypt/live/:domain_name/ in turnserver.conf, it's back online! Yay!!
So I have tried and tried to get my ssh to work with kerberos on Mavericks to no avail. Here are my versions:
ssh: OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
kerberos: Heimdal 1.5.1apple1
I also tried the built in ssh with no effect as well. Here is my config:
ForwardAgent yes
GSSAPIAuthentication yes
GSSAPIDelegateCredentials yes
GSSAPIKeyExchange yes
i have checked, there are no overriding settings in my user config
After all of this, I still get prompted for a password when ssh'ing to a linux host that does work with linux clients. (I am able to successfully kinit and i do get a ticket)
Any clues what I am missing? Has anyone has this problem before.
HERE is a link to the ssh connection log. It just seems to abandon gssapi without even trying it... why????
NOTE ON OSX SIERRA:
It appears that Apple broke it again.... The gssapitrusdns stuff is actually a third-party contribution and Apple revved to a newer ssh that doesn't include those patches... See HERE and HERE
ORIGINAL ANSWER (pre Sierra):
Ok, so after even more head-scratching, giving up, and violent attempts to strangle my computer with a power cord, I have found the answer... Turns out, OSX need to be told to explicitly trust DNS.... Add the following line to your ssh config:
GSSAPITrustDNS yes
Source (check the 'Problems and Workarounds' section)
From the logs it looks like server is sending "gssapi-keyex,gssapi-with-mic" methods but somehow client doesn't have support for it.
Look at this logs
preferred publickey,keyboard-interactive,password
can you check your client whether it supports it or not ?
you can check client config file /user//.ssh/config -> on linux system.
I am having a problem with my server and so far couldn't find any solution for this. When I try to add a server from a server manager (windows server 2012) I can see only the kerberos security error. Both servers are in the same domain(i have tried from several servers from domain and got the same error).
The strange thing is when I unjoin the problematic server from domain and rejoin it with another name it works normally. But the problem is to make it work with existing name. Anyhelp will be highly appreciated
thanks in advance.
Late reply, but I've just encountered the same error and hope this solution proves useful to others.
Situation: I had to wipe and reinstall a virtual server on which I'd previously had to set some Service Principal Names, and some SPNs for a service account. Turns out the SPNs were still there for the old server/account and I had to remove them.
I recommend checking for and removing rogue SPNs to resolve this. Use the following commands in an elevated command prompt:
setspn -l <servername/username>
In my case I had problems with MBAM, the Bitlocker admin tool, so for example I used:
setspn -l mbam01
Which gave me the output (changed names to protect the innocent):
Registered ServicePrincipalNames for CN=MBAM01,OU=Member Servers,DC=corp,DC=domainname,DC=com:
termserv/mbam01.corp.domainname.com
termserv/mbam01
http/mbam01.corp.domainname.com
http/mbam01
HOST/MBAM01
HOST/mbam01.corp.domainname.com
This will list the SPNs associated with the server or user account. Then you remove the errant SPNs with this command:
setspn -d <listed service> <servername/username>
In my case it turned out the mbamapppool user had http/mbam01 and http/mbam01.corp.domainname.com associated with it, causing Server Manager to fail to poll the server. I removed the http/ refs from the user and then added them to the server with the following commands:
setspn -d http/mbam01 corp\mbamapppooluser
setspn -d http/mbam.corp.domainname.com corp\mbamapppooluser
setspn -s http/mbam01 mbam01
setspn -s http/mbam01.corp.domainname.com mbam01
I then refreshed Server Manager and it polled the server successfully, and the Kerberos Security Error had gone.
I use sourcerepo.com as SVN server. My XCode5 bot complains : error validating server certificate for "https://myproject.sourcerepo.com:443"
- the certificate is not issued by a trusted authority. Use the fingerprint etc....
How can I make my XCode Server accept this svn server and retrieve sources ?
thanks for your advice
Frank
Verify why the certificate is untrusted. (E.g., is it a self-signed certificate?)
Start Terminal and run svn info https://myproject.sourcerepo.com:443/<path-to-repository>. Accept the certificate permanently when prompted.
I found a way to make it work from the Xcode 5 release notes:
https://developer.apple.com/library/ios/releasenotes/developertools/rn-xcode/xc5_release_notes/xc5_release_notes.html
Communicating with a remote SVN repository over HTTPS can fail with an
error similar to “Error validating server certificate for server
name.” Edit the file
/Library/Server/Xcode/Config/xcsbuildd.plist
and change the TrustSelfSignedSSLCertificates key from false to true.
Then, from a Terminal window, run:
sudo killall xcsbuildd
I did exactly the above. To edit the file you actually need to
sudo vi /Library/Server/Xcode/Config/xcsbuildd.plist
After restarting the build daemon I was able to get my Xcode bot to checkout the sources from the remote repository and perform the integration. Hope this helps!
I made my own git server on a centos distribution.
I can contact the server via git protocol at my home. But when I try to access via https at office I obtain:
Cloning into /Users/vito/Documents/... error:
error:14077458:SSL routines:SSL23_GET_SERVER_HELLO:reason(1112) while
accessing https://gitolite#myserverxyz.com/vitorepo.git/info/refs
fatal: HTTP request failed
Where is the problem? On my server or on my office-mac?
I got the exact same response from curl when trying to connect with an ubuntu instance running openssl 1.0.0e. I successfully resolved the problem by adding the -ssl3 flag to the curl command.
It seems that it's a compatibility problem between older version of OpenSSL (0.9.8) acting as a client and recent OpenSSL version (1.0.0) acting as a server with some specific options used by Curl on client side and Apache on server side.
It's probably due to some recent security fix in OpenSSL (probably the one against protocol downgrade attacks).
Try upgrading the OpenSSL library version on the client side to 1.0.0.
See:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=3395520&group_id=976
In case anyone has this issue with XMLRPC.
Daniel's answer (forcing SSL version 3) solved the issue for me. just specify XMLRPC_SSLVERSION_SSLv3 in the clientXmlTransport_curl options (C++).
The problem began when we upgraded our server to OpenSSL version 1.0.1-4ubuntu5.5 and the clients were still running 0.9.8o-5ubuntu1.7.
I believe this is a host-name matching issue on the server. Error 1112 is SSL_R_TLSV1_UNRECOGNIZED_NAME, and comes from an SNI name mismatch (info on SNI). I was having the same issue in curl.
For me, the work around was to make sure the name I used on the client matched one of the ServerName or ServerAlias configurations on the server. Of course, these commands are for an apache server; I don't know what you need to do for a git server. But I suspect the server names you're using from home and work are different, and the home name is the cannonical name the git server is using (and therefore SNI is working).
The 'real' fix will probably take a client change in git to allow a way to ignore the name-mismatch warning (the way your browser already does).
Not sure if I had exactly the same problem, but the error message was the same. It only seemed to be happening on the ubuntu box I set up a git server on, for some reason the centos box with a git server set up on it was fine.
I only just solved it after 3 or 4 days. It turns out to be because git's underlying Curl library has a broken Keep-alive implementation (I ended up dumping HTTP traffic and verifying the behaviour by hand).
In a nutshell Curl (at least the version used inside every Git implementation I could find, including command line git and eclipse's EGit) doesn't seem to correctly interpret the Connection response header, or more correctly doesn't seem to correctly interpret the absence of it.
To fix the problem you need to configure the SSL virtual host inside the apache that is serving your GIT repository with an extra directive specifically for git. Add these lines just before the </VirtualHost>.
BrowserMatch "git" nokeepalive ssl-unclean-shutdown
You unfortunately can't tell apache to just downgrade to HTTP/1.0 (would be cleaner) because Curl can't handle that, but you can just tell it to force a Connection:close on every request which Curl does know how to handle.
In a misleading coincidence, if you try to test Curl directly without this change it will seem to work, because it makes a single request and then aborts. Only by getting curl to execute two requests on the same keep-alive connection over ssl will this problem become apparent.
I had the same error. The root cause seems to be incompatibility of client/server openssl versions.
I've upgraded my server with apt-get upgrade openssl and upgraded my windows git installation.
The combination of windows git client
git version 1.9.4.msysgit.0, which contains openssl version:
OpenSSL 0.9.8e 23 Feb 2007
And server with openssl version:
OpenSSL 1.0.1c 10 May 2012
seems to work fine together.