Re: Renewing certificates and public key tokens
From: William Stacey [MVP] (staceywREMOVE_at_mvps.org)
Date: 03/01/05
- Next message: Frank Rizzo: "Re: UDP Blues"
- Previous message: Sean Hederman: "Re: How about Data Access Application Block"
- In reply to: Mike Schilling: "Renewing certificates and public key tokens"
- Messages sorted by: [ date ] [ thread ]
Date: Tue, 1 Mar 2005 00:26:27 -0500
Why are you using certificates for the SN? Why not just create a .snk and use that? Then you don't have to worry about expire and can use same public key for all versions.
-- William Stacey, MVP http://mvp.support.microsoft.com "Mike Schilling" <mscottschilling@hotmail.com> wrote in message news:eLEaWMfHFHA.3844@TK2MSFTNGP14.phx.gbl... The certificate we use to sign our assemblies was about to expire, so I contacted Verisign to renew it. The new certificate came, we installed it, we pointed out nightly build at it, the new DLLs got signed, so far so good. The problem is that, when we looked at the with ILDASM, we noticed that the public keys tokens are different from the ones generated by the older certificate. This is a compatibility problem, of course. It's not possible to issue a bindingRedirect from a version signed with the older certificate to one signed with the new one, since .NET considers them different assemblies, not two versions of the same assembly. Verisign insists that renewed certificates always have different public keys, and this is just how things work, but I can't picture that an unavoidable incompatibility is created every year when certificates expire. What am I (or are they) missing?
- Next message: Frank Rizzo: "Re: UDP Blues"
- Previous message: Sean Hederman: "Re: How about Data Access Application Block"
- In reply to: Mike Schilling: "Renewing certificates and public key tokens"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
