Since there is now the ability to delete components from managed packages, I would like to remove 2 custom fields, but in Develop section, they are no longer listed, so how can I delete these?  They are displayed in Create | Packages

Deleting Components from Managed Packages
https://help.salesforce.com/HTViewHelpDoc?id=viewing_deleted_components.htm&language=en_US

We have a GeoTrust certificate that is on the list of Salesforce approved certs. GeoTrust Global CA and the intermediate certificate GeoTrust DV SSL CA.

 

This certificate is used for a secure Apex callout to our web service  It has been working since February.  But on September 27, we were getting errors that indicated that Salesforce no longer recognized our certificate.  Also a customer using IE8 reported that several users were getting untrusted message.

 

We only have one intermediate certificate and both are installed correctly on IIS.  We did not have any issues with Salesforce or any browsers from February until September 27.  We are using Wndows Azure and I believe that Microsoft upgraded IIS7 to IIS8 recently, but don't know if that is relevant..

 

On September 27 I ran SSL Checker on SSL Shopper and found that our certificate path is not trusted by all browsers.   I was told by GeoTrust that IE8 has trouble sometimes when this warning appears.  He confirmed that we just needed to make sure the intermediate and root cert are stored correctly on IIS which they are. 

 

When I added our URL to the hostHeader setting on IIS, there was no longer any warning on SSL Checker and Salesforce correctly recognized our chain of trust.

 

But I don't want to use a hostHeader setting and wondering if Salesforce needs to update its code to avoid the same issue IE8 has in resolving the correct certificate path.    (Using a hostHeader setting creates issues when publishing our application to staging because the hostHeader is not correct.)

 

 

For the HttpRequest Class, setBody has a limit of 3 MB:

 

http://www.salesforce.com/us/developer/docs/apexcode/Content/apex_classes_restful_http_httprequest.htm

 

set Compressed sends the data in the body in compressed format.

 

I would hope that the 3 MB applies to the compressed data, but this is not clear in the documentation.

We are using an Apex Callout using a SOAP WSDL and now want to use gzip compression.  I understand we can do this if we change our code and use HTTP classes instead, but that should not be necessary.

 

With respect to SOAP responses, the documentation says:

 

"The API can optionally compress responses. Responses are compressed only if the client sends an Accept-Encoding header with either gzip or deflate compression specified."

But our callout occurs by a scheduler so how can we use gzip compression for these callouts?

We purchased an EssentialSSLWildcard certificate which is an intermediate certificate (3 intermediate certificates).  We have installed AddTrustExternalCARoot certificate from Comodo as well as the necessary intermediate certificates on both IIS and Windows Azure.  The thumbprint of the root certificate matches the thumbprint of the addtrustexternalca  certificate listed as the second certificate http://wiki.developerforce.com/page/Outbound_Messaging_SSL_CA_Certificates#addtrustexternalca

 

All intermediate certificates are installed properly:
http://www.sslshopper.com/ssl-checker.html#hostname=app.fantasysalesteam.com 

 

But we still get the error when trying to connect to our web service from Salesforce "unable to find valid certification path to requested target".  

 

It seems that Salesforce is not finding the path to the root certificate.

 

--------------------------

I have now determined that the certification path was to a different Comodo root certicate than the one I was provided.  I removed the old one from IIS and recreated the pfx file for uploading to Azure.

 

 

 

 

We have developed an app that posts to a web service data with certain associatd activity dates in the format YYYY-MM-DD.  Do we need to add anything to our code to deal with a customers who install the app and use a different date format because of their Locale setting?

CxViewer reports 6 Test Methods With No Assert and no other warnings or threats.  Can we proceed to security review without fixing these? 

 

Even if not required to fix for securitty review, is there likely to be any benefit to fixing these?

 

We purchased an EssentialSSLWildcard certificate which is an intermediate certificate (3 intermediate certificates).  We have installed AddTrustExternalCARoot certificate from Comodo as well as the necessary intermediate certificates on both IIS and Windows Azure.  The thumbprint of the root certificate matches the thumbprint of the addtrustexternalca  certificate listed as the second certificate http://wiki.developerforce.com/page/Outbound_Messaging_SSL_CA_Certificates#addtrustexternalca

 

All intermediate certificates are installed properly:
http://www.sslshopper.com/ssl-checker.html#hostname=app.fantasysalesteam.com 

 

But we still get the error when trying to connect to our web service from Salesforce "unable to find valid certification path to requested target".  

 

It seems that Salesforce is not finding the path to the root certificate.

 

--------------------------

I have now determined that the certification path was to a different Comodo root certicate than the one I was provided.  I removed the old one from IIS and recreated the pfx file for uploading to Azure.

 

 

 

 

We have a GeoTrust certificate that is on the list of Salesforce approved certs. GeoTrust Global CA and the intermediate certificate GeoTrust DV SSL CA.

 

This certificate is used for a secure Apex callout to our web service  It has been working since February.  But on September 27, we were getting errors that indicated that Salesforce no longer recognized our certificate.  Also a customer using IE8 reported that several users were getting untrusted message.

 

We only have one intermediate certificate and both are installed correctly on IIS.  We did not have any issues with Salesforce or any browsers from February until September 27.  We are using Wndows Azure and I believe that Microsoft upgraded IIS7 to IIS8 recently, but don't know if that is relevant..

 

On September 27 I ran SSL Checker on SSL Shopper and found that our certificate path is not trusted by all browsers.   I was told by GeoTrust that IE8 has trouble sometimes when this warning appears.  He confirmed that we just needed to make sure the intermediate and root cert are stored correctly on IIS which they are. 

 

When I added our URL to the hostHeader setting on IIS, there was no longer any warning on SSL Checker and Salesforce correctly recognized our chain of trust.

 

But I don't want to use a hostHeader setting and wondering if Salesforce needs to update its code to avoid the same issue IE8 has in resolving the correct certificate path.    (Using a hostHeader setting creates issues when publishing our application to staging because the hostHeader is not correct.)

 

 

We purchased an EssentialSSLWildcard certificate which is an intermediate certificate (3 intermediate certificates).  We have installed AddTrustExternalCARoot certificate from Comodo as well as the necessary intermediate certificates on both IIS and Windows Azure.  The thumbprint of the root certificate matches the thumbprint of the addtrustexternalca  certificate listed as the second certificate http://wiki.developerforce.com/page/Outbound_Messaging_SSL_CA_Certificates#addtrustexternalca

 

All intermediate certificates are installed properly:
http://www.sslshopper.com/ssl-checker.html#hostname=app.fantasysalesteam.com 

 

But we still get the error when trying to connect to our web service from Salesforce "unable to find valid certification path to requested target".  

 

It seems that Salesforce is not finding the path to the root certificate.

 

--------------------------

I have now determined that the certification path was to a different Comodo root certicate than the one I was provided.  I removed the old one from IIS and recreated the pfx file for uploading to Azure.