I have created a certificate request for code signing purposes. The sys admins told me they have never given one before and told me they need to set up local windows certificate issuing to hand out certificates for code signing purposes. They have sent me a certificate base 64 encoded once it is enabled. I imported cert into my pc and tried to sign the microsoft access. Microsoft access claims the digital signature is not valid.
When I look at the signature, it looks valid. Is there anyway I can debug why the cert is no good for code signing purposes ? Thanks.
That was dumb but here's what happened. When I went through the certmgr, it did not let me request a certificate through the AD policy. I had to create a request using the custom request. What I did not realize is that, I was issuing the command from another computer and sending the request and then importing the certificate from another computer.
Basically I did not have a private key on the other computer to sign the certificate, the certificate looked ok but the prompt that says "you have a private key ..." was not there. When I went in and imported the certificate, on the same computer that I have created the request from, the private key was found and I was able to sign it. That was stupid but you think, I would get a more descriptive warning.
Of course now that I have signed my access 2007 package, I figured out it, it still gives me a warning about macros and asks me to still enable.. My understanding was that signing your package will let others to run the content without running into trust center issues... Fudge....
Related
If I access my glassfish server at http://localhost:8080, I receive the glassfish welcome page, as it should be. But if I try to access the other http listener at https://localhost:8181, I receive a message like that:
(illustrative image)
How can I avoid this error message (thinking that I don't want my clients to see it)?
This is because GlassFish generates self-signed certificates for authentication (s1as and glassfish-instance). Your browser is (rightly) complaining that it doesn't trust these certificates, because anyone can fake them for a "man-in-the-middle" attack.
To get around this, you will need to obtain a new private key and certificate from a trusted CA to replace the self-signed ones.
These can then be imported to your keystore,jks and cacerts.jks, or you can create new keystores. If you're unfamiliar with how this works, I would suggest making backups of the originals, then importing to the existing keystores, since the communication between DAS and instances relies on certificates for authentication in a lot of places.
The GlassFish 4 Security Guide [PDF] should help you.
I have an app on a custom domain on Google App Engine and I need to capture JSON packages.
I am using http://www.hurl.it/ to test and the url is like: https://subdomain.website.net.au/folder/
This give a server error however if I remove the S and just use HTTP the request works fine. What does Google need in order for this to work?
Update:
Using Curl and running the following command:
curl --verbose --data "#json.txt" --header "Content-Type:application/json" "https://subdomain.website.net.au/folder/"
I get the error: "unable to get local issuer certificate"
When I download the cert file from http://curl.haxx.se/ca/cacert.pem and run:
curl --verbose --cacert "cacert.pem" --data "#json.txt" --header "Content-Type:application/json" "https://subdomain.website.net.au/folder/"
It works fine and as expected. Does this mean the issue is with hurl.it? if so what is the issue exactly, I have a customer trying to send me data and it is not working either.
Update2:
The issue ended up being that the client did not support SNI so I had to use a VIP instead. This costs money, is an older method but more compatible.
There is an article on how to setup SSL for custom domains on developers.google.com.
Basically you need two things:
An SNI or Virtual IP Certificate
Your domain has to be a payed Google Apps domain to install the certificate
Your certificate, your Google Apps Domain and using the certificate with App Engine will cost you. If you can use the YOURAPPID.appspot.com domain instead you get SSL for free. If you need your custom domain i recommend the above website.
After Updating your Question:
It looks like the Certificate Authority (CA) is unknown or untrusted to the client. This can be fixed by using a commercial certificate from thawte or verisign. Or, you can add the CA certificate to the certificate store of your operating system or client application.
In other words: Install the CA cert as trusted root certificate in your operation system or app. That should do.
Oh and your assumption is right. hurl.it does not know the CA and thus rejects your certificate as invalid or unknown issuer.
Update 2:
Craig, your GeoTrust cert should be fine. Please try the following:
Please verify if you can visit this or any other page hosted by your app with a normal web browser. It should not complain about the certificate. If it does and you need to add an exception rule for the certificate then something is still wrong configuration wise.
I haven't done this in a while but last time i used an SSL certificate i concatenated the actual certificate and the CA somehow, i'm sure there are tutorials for this. Because the CA.cert isn't found it makes sense to provide it in this manner.
From developers.google.com:
'A certificate file can contain at most five certificates; this number includes chained and intermediate certificates.'
See also wikipedia
Since it does work with curl when you supply the CA manually that is a temporary solution for your customer to upload data.
Note that not all applications use the system store for certificates. Firefox for example has its own certificate store and it completely ignores all changes you do in the root certificate store of the operating system (at least under windows that is the case)
Once you have verified that the website works with HTTPS (see 1) you can create a simple form in that app containing a textarea in which you can paste your JSON data and send it to your app using jquery or something. While this is not ideal it is an excellent test to verify that your app and SSL setup works and the issue is somewhere else.
If upload is all you need at the moment you could always package curl and the CA.cert together and add a small batch file that makes the appropriate call.
This is all the information i can give you without having a look at your actual setup. My advice is to fiddle around with clients and certificates because that's definetly where this issue is. It has nothing to do with the JSON data.
We are trying to sign a Windows 8.1 Store application with a corporate certificate obtained from Symantec. The certificate was originally ordered for Windows Phone 8 application signing, but the same certificate should work for Windows 8.1 apps also.
On a fresh Hello World -project, when we try to choose the certificate from the manifest designer in Visual Studio 2013, an error message is given: "The Manifest Designer could not import the certificate. The certificate you selected is not valid for signing because it is either expired or has another issue. For more information, see http://go.microsoft.com/fwlink/?LinkId=241478."
The certificate is most certainly not expired. On the "another issue" angle, a common suggestion for a possible cause for this issue was a publisher name mismatch between the certificate and the application, but that has been ruled out. If we skip some signing checks by adding a EnableSigningChecks=false to the .csproj file, we can sign the app, but then another error is given by PowerShell when trying to install the application: "Error: The certificate can't have the following extended key usage: 2.16.840.1.113733.1.8.52.1." Only the Code Signing and Lifetime Signing EKUs are allowed."
We asked for help on this issue from Symantec and Microsoft, but they didn't know how to help with this issue.
Has anybody encountered a similar issue with signing their apps? Is there a solution to this problem?
This issue looks to be the same as in Choosing a certificate for a Windows Store application via the package.appxmanifest, where the solution was to get a new certificate. Is the only thing we can do to just buy a new certificate?
In my wp8 app,
I enter a open wifi which is operated by communication operator
blocked by a portal page that needs using account and password to log in
after I post some data to a https url
I have the ability to use the wifi network to access to internet freely.
Now,I encounter a problem:
before the https connection established successfully,it will be running the Online Certificate Status Protocol (OCSP)
OCSP needs to access to CA like veriSign to verify the server certificate status
but I have no internet access at this moment.
So,my app return a Webexception whose description is "The remote server returned an error: NotFound".I think it is because of the failure of OCSP.
Based on above,I want to find a solution to sovle this:
My point is to disable the OCSP mechanism，Do you know how to do this?
And I also would like to know if there is another solution to sovle the problem.
Hope your advice,Thanks!
The way you'd do that on .NET is to set the ServicePointManager.ServerCertificateValidationCallback delegate and perform the logic you want to perform. But, unfortunately that is not yet available on Windows Phone.
There are various uservoice suggestions related to this, for example:
http://windowsphone.uservoice.com/forums/101801-feature-suggestions/suggestions/2146033-allow-self-signed-and-corporate-certificates-for-s
http://windowsphone.uservoice.com/forums/101801-feature-suggestions/suggestions/4299617-client-ssl-certificate-authentication
They don't apply to you directly, but if they end up gaining access to ServicePointManager then you'll be able to do what you want to do.
I have successfully set up health monitoring for logging errors on my ASP.NET web page to the Windows Event Log, a SQL Server database, and through email (Microsoft Exchange) when I specify a user name and password in the web.config file. However, if I change from specifying a user name and password to defaultCredentials="true" in web.config, I get the following error message in my Windows Event Log when it tries to generate the email:
System.Web.HttpException (0x80004005): Unable to send out an e-mail to the SMTP
server. Please ensure that the server specified in the <smtpMail> section is
valid. ---> System.Net.Mail.SmtpException: Mailbox unavailable. The server
response was: 5.7.1 Client does not have permissions to send as this sender
I am running Windows Vista on a corporate domain. My Windows login is identical to my Microsoft Exchange login. Can anyone provide some insight as to why specifying my login credentials explicitly in the web.config file works, but using defaultCredentials="true" does not? Are there any known solutions so that I can have an automated email sent through healthMonitoring without having to store my user name and password in the web.config file?
Since I earned the tumbleweed badge for this question, I doubt an answer will be of much value to anyone else; but knowing that I will inevitably fall into the same trap at a later date, I thought I would post an answer to my own question...
Authentication is not necessary for sending emails within the same domain; so instead of specifying defaultCredentials="true", I removed all fields related to authentication, and the emails began working again.
Note that this is only a partial solution. I only need to send emails to addresses within the same domain for now. Sending emails outside of this domain will not work without authentication, so if/when that is needed, it will be back to the drawing board...