Today i received an email from apple telling they are changing something connected with push notifications, and wanted to ask what to do with the certificate they gave me link to... My server runs debian lenny, and im using php5 to send push notifications to apple apns. Do i have to just like... add it somewhere, or replace the 'old' one ?
Download the entrust_2048_ca.cer file, and install it on the servers that communicate with Apple's notification services. No need to do renew your actual push certificates, also you should not have to change anything in your code.
The important thing is that the servers that actually communicate with Apple's notification services have the certificate installed.
If you are lucky, your push server is already in contact with a Certificate Authority root, and this will solve the issue for you automagically. However, if you should lose that connection, your notifications will be out of order unless you have a "local" version of the certificate.
I am looking for the same solution, a quick hint from another forum says "simply download the .cer file and install it" http://www.iphonedevsdk.com/forum/iphone-sdk-development/66878-apns-question-email-apple.html.
We will try on our linux server and please see if this works for your situation.
I downloaded and copied the https://www.entrust.net/downloads/binary/entrust_2048_ca.cer file into /etc/ssl on my OpenBSD server. I haven't changed any of my server side code which is actually not using the entrust cert in any way. (I use the certs from Apple's provisioning site.)
On Dec 23rd, my notifications are sent and received with or without the entrust cert. I am confused about how exactly I am supposed to use the entrust cer file.
I think this sentence from the email from Apple tells me I am ok:
If you have been successfully
validating the certificate chain in
the APNs sandbox environment, you
already have the root certificate you
need. Simply install the same root
certificate on your production push
provider servers.
i.e.
Notifications were and are sent, hence my server already has what it needs.
UPDATE:
What I wrote above seems to be the case. If you use a fairly recent server you likely don't have to do anything at all. The sandbox environment has been using 2048 bits since March 2010. If it has been working, you are set. Full info here:
http://www.24100.net/2010/12/latest-apple-push-notification-certificate-changes-decrypted/
My PHP5 scripts that connect to the Apple Push Server are hosted on a Fedora system. For me, the migration was transparent. I had nothing to do despite I can't find the Entrust certificate somewhere on my system. Maybe is it available with the PHP5 SSL library.
Related
I've been trying to use this documentation as guide but I am having no luck setting up a gitlab-runner on Windows. It correctly polls for jobs but when it tries to pull artifacts, it returns a x509: certificate signed by unknown authority error.
Can anyone step through how to generate the proper certificate and attach it to the Windows gitlab-runner in order to get things to work?
I've tried generating certificates using openssl and setting the --tls-ca-file flag but so far, it hasn't helped.
I got this working finally using this as a reference.
The basic idea, when you're not hosting your own gitlab server, is to pull the certificate from gitlab.com. From your browser, click on the little lock symbol next to the https://gitlab.com URL and download the certificate. From Safari, it's just dragging the little certificate image over to your Desktop.
Once you have the cert, store it in your Gitlab-Runner folder and reference it with the tls-ca-file parameter in your config.toml.
For all docusign developers outthere. I'm using Docusign Connect to check the status of the envelop. I develop a listener that runs on tomcat. The reason why I used this because it's easier to code on my perspective and I want a push type data notification.
It works fine with HTTP, but I spend 2 days now and I still can't get it work for HTTPS.
My question is since the self signed certificate is not working. Do I need to purchase an SSL certificate for my web server?
or Docusign has a work around on this?
On demo sandboxes you can get away with testing without using HTTPS.
On production you will need a server that will actually support error free SSL connections. This means that you will need to wire up your tomcat to use some certificate that validates your website address. Whether it's a new one or just a wild card that you already have - that depends on the situation.
HTH
-mb
Question: How can I securely include the SSL cert required for push notifications in the installer for my server product?
Background: Apple Push Notifications require a client SSL cert to be in place on the server that's making the calls to Apple.
My product has a traditional client/server architecture, i.e. a customer installs the server within their intranet and then obtains the iOS client from the App Store and connects the client to their instance of the server.
The point here is that the customer installs the server themselves, rather than a cloud architecture where I would manage the server myself.
My problem is that I don't know how to package the push notification certificate in the server installer in a secure way. I can't distribute the .p12 file without a password because that would expose my private key, and I can't use a password because the password would have to be included somewhere else in the installer which would defeat the purpose. Do I need to relay messages from all of my customers through a server that I manage, which has the SSL client cert? Do I need to install the SSL cert by hand into every one of my customers' sites?
Surely others must have run into this problem already? Or has everyone moved to the cloud?
Here is a major observation that happened to me over the weekend regarding Apple Push certificates. While there many references out there to setting up the Apple Push server side certificates, here is a MAJOR point I discovered that I cannot find referenced in any Apple documentation, or via google.
My situation: I have Push Certificates (sandbox) working great on Windows Server. Now it is time for production. Installation of production certs is successful like many times before. However, while the production push transmission completes error free, no pushes are generated to the device. Hmmm.
I just HAPPEN to notice that my Mac's time is roughly a minute off from the Windows Server (command-tabbing between MacOS and VM-Ware). Looking at Windows and Mac Settings, I see Windows internet time is set for "time.windows.com", and the mac for "time.apple.com". Just for kicks, I change the windows server time to "time.apple.com". Instantly, pushes are now being sent to the device. Nice. :-)
I dodged a major bullet here, this would have probably driven me insane trying to figure this one out. I do not claim to be an SSL cert guru... I (like most every one) just want to get this stuff to work because we have bigger fishes to fry.
I hope this is useful information.
I know only the solutions to install certificates for push notifications :
.p12, the password is in the code of the sending
.cer (.p12+private key) the password is requested at the importing of the certificate.
In the first case, you can deploy your solution, and download some code, for example xml with the password.
I am having trouble connecting Redmine to a locally hosted subversion repository using SSL.
I suspect it's the self-signed certificate that usually triggers a warning in the SVN client and browser.
When I try to connect to the local repo through SSL in Redmine, I get a red "Revision not available" error. When I try connecting through svn://, the connection times out, and I have to restart the web server.
Connecting without SSL works without problems.
It would be nice to run subversion on SSL to make it safely accessible from the outside as well. I could run the repository through plain HTTP but would like SSL for outside communication. As far as I understand, subversion can't be run both ways at the same time.
Does anybody know what to do in such a situation? Is there a configuration setting to ignore invalid certificates somewhere?
Looking at the source all redmine does is shell out to the svn binary, see: http://www.redmine.org/projects/redmine/repository/entry/trunk/lib/redmine/scm/adapters/subversion_adapter.rb
So if you can somehow workout how to get the binary to accept your SSL certificate then you will be good.
From http://groups.google.com/group/bitten/browse_thread/thread/d18b21a703c68344?pli=1 it seems you need some manual interaction with svn to accept the cert.
So my suggestion: run svn checkout against your repo as the user running redmine and permanently accept the cert
The reason you are getting this message is because the default user under which redmine is running (www-data) calls the “svn” client to communicate with the repositories but the client replies back to it saying that the certificate is untrusted, thus the connection is closed.
Here's a step by step fix:
http://haknick.tumblr.com/post/2380507902/redmine-svn-subversion-certificate-issue-ubuntu
since you control both the client and the server, is having the client accept the server certificate's issuing authority an option?
if it isn't a permanent option, at least you'd know if it was the problem if you did it temporarily.
I'm running mitmdump (from mitmproxy) on my Macbook Pro, and I'm connecting to the proxy through my Windows desktop PC.
However, Chrome (running on the PC) refuses to connect to so many sites because of the invalid certificates which mitmproxy provides.
Chrome throws the error: ERR::NET_CERT_AUTHORITY_INVALID
Here's what mitmdump shows:
But why? What's wrong with mitmproxy's certificates, why can't it just send back google's as if nothing happened?
I'd like to know how I can fix this and make (force) my desktop PC to connect to any website through my Macbook's mitmproxy.
Answering this question for people who may find this important now. To get the proxy working, you have to add the certificate as trusted in your browser.
For windows follow this: https://www.nullalo.com/en/chrome-how-to-install-self-signed-ssl-certificates/2/
For linux follow this: https://dev.to/suntong/using-squid-to-proxy-ssl-sites-nj3
For Mac-os follow this: https://www.andrewconnell.com/blog/updated-creating-and-trusting-self-signed-certs-on-macos-and-chrome/#add-certificate-to-trusted-root-authority
There are some additional details in the above links; tldr; import the certificate in your chrome://settings url and add the certificate as trusted. That shall do.
This will make your browser trust your self-signed certificate(mitm auto generated certificates too.)
The default certificates of mitmproxy is at ~/.mitmproxy/ directory.
Per the Getting Started page of the docs you add the CA by going to http://mitm.it while mitmproxy is running and selecting the operating system that you are using. This should solve your problem and will allow https sites to work with mitmproxy.
This is the expected behavior.
mitmproxy performes a Man-In-The-Middle attack to https connections by providing on-the-fly generated fake certificates to the client while it keeps communicating to the server over fully encrypted connection using the real certificates.
This way the communication between client and proxy can be decrypted. But the client has to actively approve using those fake certificates.
If that wasn't the case then SSL would be broken - which it isn't.
The whole story is very well explained here:
http://docs.mitmproxy.org/en/stable/howmitmproxy.html