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.
Monday, January 11, 2010
Microsoft Update Certificate Woes
Posted by
Unknown
at
9:47 AM
0
comments
Labels: certificate, Microsoft
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...
Posted by
Unknown
at
3:15 PM
0
comments
Labels: certificate, information card
Tuesday, May 27, 2008
Free SSL certificate from GoDaddy

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...
Posted by
Unknown
at
9:55 AM
1 comments
Labels: certificate, openinfocard, SSL
Friday, February 22, 2008
Renew Midlet Signing Certificate
This post is for myself and for others who always forget how this is done.
- Go to the Verisign renewal web page and request a renewal of your certificate. Have your order number at hand.
- 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----- - Copy the certificate from the email to a text file (let us call it cert2008.pem)
- Make a backup of your java keystore (keystore.jks).
- Import the new certificate into the keystore.$ keytool -keystore keystore.jks -storepass password -import -alias eclipse -file cert2008.pem
- Try it out. That is: Regenerate a signed midlet suite and deploy it to a mobile phone.
- On the mobile phone navigate to App-Manager and view the application details and the certificate details. This should show the new certificate details.



- Done.
Posted by
Unknown
at
10:31 AM
0
comments
Labels: certificate, j2me, keystore, keytool, midlet, verisign
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.
Posted by
Unknown
at
10:30 AM
1 comments
Labels: CardSpace, certificate, id selector, openinfocard, paymentCard


