Showing posts with label certificate. Show all posts
Showing posts with label certificate. Show all posts

Monday, January 11, 2010

Microsoft Update Certificate Woes

When I choose "Start -> Microsoft Update" on my Windows system IE starts and shows http://update.microsoft.com/microsoftupdate/v6/default.aspx?ln=de .
Security paranoid as I am I have HTTPS://update.microsoft.com/microsoftupdate/v6/default.aspx?ln=de in my list of "trusted" sites but not the HTTP-site. I am willing to pay the price to have to add the "s" after "http" every time. No problem.

What annoys me is that since some time ago the certificate is issued to "www.update.microsoft.com" but not for "update.microsoft.com".
I admit that maybe I am not supposed to visit this site because I edited the URL by hand but come on Microsoft: Please buy another certificate or configure the server to redirect me to the one and only with the correct certificate. (This prepending "www" to every webserver is stupid anyway. Leave that to the companies that are 90% marketing and 10% feature)

All OS-updates should be over HTTPS anyway. CPUs are cheap! Buy some more if the encryption is a performance issue. I want that extra SSL security.

Tuesday, September 09, 2008

Misconception


When I was new to Information Cards I for some time believed that it is possible to use another cert for security token signatures than for the SSL endpoint. This is not true. I thought that this is a feature for the scenario when you host your STS at a webserver provider e.g. at https://openinfocard.org/ and you don't have access to the webserver's SSL key.
During the last days I was reminded of this misconception because https://xmldap.org/sts/ was down and I wanted to deploy the XMLDAP war files to openinfocard.org...
GoDaddy support told me that they can not give me the private key of "my" SSL cert. Bummer.
Without that key I can not issue security tokens. And there is no way to specify that I am using certA for SSL protection of the endpoint and certB to sign the security token. Hm. Maybe this should be possible in the "standard"?

Certs, certs, certs everywhere...

Tuesday, May 27, 2008

Free SSL certificate from GoDaddy

GoDaddy opensource SSL certificate
Sometimes wishes become true.
I just whined about the cost for certificates but only a few hours later I found this offer from GoDaddy for opensource projects.
Have to wait how complex this gets... Sending the application was easy. Now I am waiting for approval...

Friday, February 22, 2008

Renew Midlet Signing Certificate

This post is for myself and for others who always forget how this is done.

  1. Go to the Verisign renewal web page and request a renewal of your certificate. Have your order number at hand.
  2. Wait for the new certificate to arrive via email.
    Congratulations! Verisign has issued your Java Object Signing (Class 3) Digital ID. VeriSign has digitally signed your Digital ID which gives you assurance that your Digital ID has not been damaged or changed in any way during its transmission to you.
    ...
    -----BEGIN CERTIFICATE-----
    MIAGCSqGSIb3DQEHAqCAMIACAQExADALBgkqhkiG9w0BBwGggDCCBRcwggP/oAMC
    AQICEH/ad0XLBRSPic0mS1OhhGQwDQYJKoZIhvcNAQEFBQAwgbQxCzAJBgNVBAYT
    ...
    7UlBkJmcibyvLh3KeCP5HBkPf+tovDLZiDje3D/TibQ/sYKW8aRauu0uJtPefAFu
    AAoApAaSEUgJQPkcGHlnIyTgu9XhUK4b9Q7d4C6BzYCjbFJPkXVViroi8tLqQXWI
    L2NVfR5UWpVZytk0gcBfXvZ6tQAAMQAAAAAAAAA=
    -----END CERTIFICATE-----
  3. Copy the certificate from the email to a text file (let us call it cert2008.pem)
  4. Make a backup of your java keystore (keystore.jks).
  5. Import the new certificate into the keystore.
    $ keytool -keystore keystore.jks -storepass password -import -alias eclipse -file cert2008.pem
  6. Try it out. That is: Regenerate a signed midlet suite and deploy it to a mobile phone.
  7. On the mobile phone navigate to App-Manager and view the application details and the certificate details. This should show the new certificate details.
  8. Done.

Monday, December 10, 2007

xmldap paymentCard_sts certificate

Kim Cameron noted that the certificate of the xmldap paymentCard_sts was expired. This is/was my fault. I used the wrong key alias and selected the expired certificate instead of the current one.
I changed the application's configuration today. Now I am able to create a card and import it into CardSpace, which formerly complained about the expired certificate and refused to import the managed card.


Please note that the paymentCards are importable into CardSpace but not usable with CardSpace, because the claims can not match.
The card has the claim "http://schemas.xmlsoap.org/PaymentCard/trandata?", while the relying party requires the claim e.g. "http://schemas.xmlsoap.org/PaymentCard/trandata?price=2700EUR". These claims do not match and thus CardSpace marks the paymentCard as not applicable.

Here is the same card, that I previously imported into CardSpace, used in the openinfocard id selector:


Please note that the value of the variable claim is displayed to the user.