"jcm" <j**@discussions.microsoft.com> wrote in message
news:A0FE3605-8104-4B27-8897-F96E8CC3D2D9@microsoft.com...
>I have to import a public key certificate file (.cer) to verify a
>signature.
> If the certificate has a generalizedTime notBefore element with a date
> prior
> to 1 Jan 1601, I get the error "Cannot find the requested object".
> Manually
> editing the cert to have the later date will at least allow loading of the
> certificate. This happens even in the Certificates Add-in for MMC (not the
> same error, just a very generic failure, but it seems like the same
> problem).
>
> It fails doing somethnig as simple as this:
>
> X509Certificate2 certificate = new X509Certificate2(certFile);
>
> The same certificate (with a date prior to year 1601, even 0000) will load
> using Java apis.
>
> So is this a bug in the Windows security apis? I have a third party tool
> that has generated existing certificates that I need to use, but can't
> because of this limitation.
>
> --
> Joe

"Joe Kaplan" wrote:

> Perhaps you could post the PEM format of one of the offending certs so that
> people could look at it?
>
> However, I'd also suggest that if Windows chokes on a cert with one of these
> dates that you just avoid using such old not-before dates.  It is hard to
> imagine why you'd need a cert with a validity that precedes the actual
> invention of x509 certs in general.
>
> --
> Joe Kaplan-MS MVP Directory Services Programming
> Co-author of "The .NET Developer's Guide to Directory Services Programming"
> http://www.directoryprogramming.net
> "jcm" <j**@discussions.microsoft.com> wrote in message
> news:A0FE3605-8104-4B27-8897-F96E8CC3D2D9@microsoft.com...
> >I have to import a public key certificate file (.cer) to verify a
> >signature.
> > If the certificate has a generalizedTime notBefore element with a date
> > prior
> > to 1 Jan 1601, I get the error "Cannot find the requested object".
> > Manually
> > editing the cert to have the later date will at least allow loading of the
> > certificate. This happens even in the Certificates Add-in for MMC (not the
> > same error, just a very generic failure, but it seems like the same
> > problem).
> >
> > It fails doing somethnig as simple as this:
> >
> > X509Certificate2 certificate = new X509Certificate2(certFile);
> >
> > The same certificate (with a date prior to year 1601, even 0000) will load
> > using Java apis.
> >
> > So is this a bug in the Windows security apis? I have a third party tool
> > that has generated existing certificates that I need to use, but can't
> > because of this limitation.
> >
> > --
> > Joe
>
>

"jcm" <j**@discussions.microsoft.com> wrote in message
news:EFD83D4B-6964-44CF-8E67-A891F05DB979@microsoft.com...
> Hi Joe,
>
> Thanks for the reply. The problem is that I can't force already existing
> certificates to change their dates. It's more of a legacy problem. I
> suppose
> I don't really expect a fix to the problem, but maybe there's some
> workaround
> or just an acknowledgment that it's not me, it's the Microsoft API's. I'm
> new
> to security in general, as you might be able to tell. Here's the sample
> certificate (PEM is at the bottom). Again, thanks for the help!
>
> --
> Joe
>
> Certificate:
>    Data:
>        Version: 3 (0x2)
>        Serial Number: 1 (0x1)
>        Signature Algorithm: sha1WithRSAEncryption
>        Issuer: C=US, O=Organization Name.00000001, CN=Issuer
> Name/emailAddress=email@issuer_name.com
>        Validity
>            Not Before: Jan  1 12:00:00 0 GMT
>            Not After : Dec 31 12:00:00 9999 GMT
>        Subject: C=US, O=Organization Name.00000001, CN=Issuer
> Name/emailAddress=email@issuer_name.com
>        Subject Public Key Info:
>            Public Key Algorithm: rsaEncryption
>            RSA Public Key: (1024 bit)
>                Modulus (1024 bit):
>                    00:b8:c3:5c:86:57:56:a7:67:da:dd:65:7c:06:4c:
>                    eb:e2:98:6e:88:db:e2:f0:4d:ff:ec:c0:99:70:2f:
>                    a1:42:1f:ca:01:9e:97:c6:ec:ca:35:3c:57:77:53:
>                    4b:bd:2d:12:08:24:84:36:4a:1a:9b:10:27:07:f5:
>                    c3:a2:d8:44:f9:76:37:7d:b1:f4:4c:d5:24:4e:53:
>                    ff:75:5c:b4:be:49:83:5b:af:8d:3c:57:87:e6:93:
>                    61:5e:df:30:30:74:72:6d:2d:5e:c5:46:58:c9:22:
>                    4c:57:1a:08:ff:a5:3a:c3:b1:9b:fe:f5:44:a7:f8:
>                    c2:d5:d0:40:c8:c8:5e:7f:59
>                Exponent: 65537 (0x10001)
>        X509v3 extensions:
>            X509v3 Subject Key Identifier:
>                2F:71:BC:8F:B4:E5:67:C2:35:C4:57:EF:72:35:25:97:D0:6C:8A:D9
>            X509v3 Authority Key Identifier:
>                DirName:/C=US/O=Organization Name.00000001/CN=Issuer
> Name/emailAddress=email@issuer_name.com
>                serial:01
>
>            X509v3 Basic Constraints:
>                CA:TRUE
>            X509v3 Key Usage:
>                Certificate Sign
>            X509v3 Subject Alternative Name:
>                email:email@issuer_name.com
>            X509v3 Issuer Alternative Name:
>                email:email@issuer_name.com
>    Signature Algorithm: sha1WithRSAEncryption
>        6a:8e:f0:82:55:50:66:c7:5b:ff:bb:ba:84:eb:b1:70:46:c1:
>        a9:98:8e:db:0d:05:b2:01:da:e9:b3:2a:95:7c:46:95:94:b1:
>        26:47:05:4d:1e:97:d9:72:fc:dd:b0:e5:48:ff:97:cc:39:13:
>        5c:65:9e:dd:7d:c9:fa:ff:a1:e8:30:23:6a:1a:47:13:f8:01:
>        36:29:ac:35:f7:bf:ac:0c:86:cc:80:d6:4c:27:9d:dd:65:93:
>        ba:96:68:4f:0d:c8:61:54:16:00:1f:b6:56:c2:e4:4c:80:82:
>        49:2f:eb:01:31:2f:0a:68:c8:1e:c8:8e:d9:28:3d:4d:d6:17:
>        98:e5
> -----BEGIN CERTIFICATE-----
> MIIDXTCCAsagAwIBAgIBATANBgkqhkiG9w0BAQUFADBuMQswCQYDVQQGDAJVUzEj
> MCEGA1UECgwaT3JnYW5pemF0aW9uIE5hbWUuMDAwMDAwMDExFDASBgNVBAMMC0lz
> c3VlciBOYW1lMSQwIgYJKoZIhvcNAQkBDBVlbWFpbEBpc3N1ZXJfbmFtZS5jb20w
> IhgPMDAwMDAxMDExMjAwMDBaGA85OTk5MTIzMTEyMDAwMFowbjELMAkGA1UEBgwC
> VVMxIzAhBgNVBAoMGk9yZ2FuaXphdGlvbiBOYW1lLjAwMDAwMDAxMRQwEgYDVQQD
> DAtJc3N1ZXIgTmFtZTEkMCIGCSqGSIb3DQEJAQwVZW1haWxAaXNzdWVyX25hbWUu
> Y29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC4w1yGV1anZ9rdZXwGTOvi
> mG6I2+LwTf/swJlwL6FCH8oBnpfG7Mo1PFd3U0u9LRIIJIQ2ShqbECcH9cOi2ET5
> djd9sfRM1SROU/91XLS+SYNbr408V4fmk2Fe3zAwdHJtLV7FRljJIkxXGgj/pTrD
> sZv+9USn+MLV0EDIyF5/WQIDAQABo4IBBTCCAQEwHQYDVR0OBBYEFC9xvI+05WfC
> NcRX73I1JZfQbIrZMIGABgNVHSMEeTB3oXKkcDBuMQswCQYDVQQGDAJVUzEjMCEG
> A1UECgwaT3JnYW5pemF0aW9uIE5hbWUuMDAwMDAwMDExFDASBgNVBAMMC0lzc3Vl
> ciBOYW1lMSQwIgYJKoZIhvcNAQkBDBVlbWFpbEBpc3N1ZXJfbmFtZS5jb22CAQEw
> DAYDVR0TBAUwAwEB/zALBgNVHQ8EBAMCAgQwIAYDVR0RBBkwF4EVZW1haWxAaXNz
> dWVyX25hbWUuY29tMCAGA1UdEgQZMBeBFWVtYWlsQGlzc3Vlcl9uYW1lLmNvbTAN
> BgkqhkiG9w0BAQUFAAOBgQBqjvCCVVBmx1v/u7qE67FwRsGpmI7bDQWyAdrpsyqV
> fEaVlLEmRwVNHpfZcvzdsOVI/5fMORNcZZ7dfcn6/6HoMCNqGkcT+AE2Kaw197+s
> DIbMgNZMJ53dZZO6lmhPDchhVBYAH7ZWwuRMgIJJL+sBMS8KaMgeyI7ZKD1N1heY
> 5Q==
> -----END CERTIFICATE-----
>
>
> "Joe Kaplan" wrote:
>
>> Perhaps you could post the PEM format of one of the offending certs so
>> that
>> people could look at it?
>>
>> However, I'd also suggest that if Windows chokes on a cert with one of
>> these
>> dates that you just avoid using such old not-before dates.  It is hard to
>> imagine why you'd need a cert with a validity that precedes the actual
>> invention of x509 certs in general.
>>
>> --
>> Joe Kaplan-MS MVP Directory Services Programming
>> Co-author of "The .NET Developer's Guide to Directory Services
>> Programming"
>> http://www.directoryprogramming.net
>> "jcm" <j**@discussions.microsoft.com> wrote in message
>> news:A0FE3605-8104-4B27-8897-F96E8CC3D2D9@microsoft.com...
>> >I have to import a public key certificate file (.cer) to verify a
>> >signature.
>> > If the certificate has a generalizedTime notBefore element with a date
>> > prior
>> > to 1 Jan 1601, I get the error "Cannot find the requested object".
>> > Manually
>> > editing the cert to have the later date will at least allow loading of
>> > the
>> > certificate. This happens even in the Certificates Add-in for MMC (not
>> > the
>> > same error, just a very generic failure, but it seems like the same
>> > problem).
>> >
>> > It fails doing somethnig as simple as this:
>> >
>> > X509Certificate2 certificate = new X509Certificate2(certFile);
>> >
>> > The same certificate (with a date prior to year 1601, even 0000) will
>> > load
>> > using Java apis.
>> >
>> > So is this a bug in the Windows security apis? I have a third party
>> > tool
>> > that has generated existing certificates that I need to use, but can't
>> > because of this limitation.
>> >
>> > --
>> > Joe
>>
>>

"Joe Kaplan" wrote:

> My Vista client won't open that cert in the GUI at all and says the format
> is invalid, so this looks like a problem that is more core to Windows than
> anything specific to .NET.  OpenSSL will dump out the cert although I'm
> confused on the sematics of the year 0.  :)
>
> You'd have to probably take this up with Microsoft and get a reading from
> them as to whether there is something out of compliance with the X509 spec
> or a bug in Windows.  It looks like there is no way that any native MS
> crypto APIs will load this cert though.
>
> --
> Joe Kaplan-MS MVP Directory Services Programming
> Co-author of "The .NET Developer's Guide to Directory Services Programming"
> http://www.directoryprogramming.net
> "jcm" <j**@discussions.microsoft.com> wrote in message
> news:EFD83D4B-6964-44CF-8E67-A891F05DB979@microsoft.com...
> > Hi Joe,
> >
> > Thanks for the reply. The problem is that I can't force already existing
> > certificates to change their dates. It's more of a legacy problem. I
> > suppose
> > I don't really expect a fix to the problem, but maybe there's some
> > workaround
> > or just an acknowledgment that it's not me, it's the Microsoft API's. I'm
> > new
> > to security in general, as you might be able to tell. Here's the sample
> > certificate (PEM is at the bottom). Again, thanks for the help!
> >
> > --
> > Joe
> >
> > Certificate:
> >    Data:
> >        Version: 3 (0x2)
> >        Serial Number: 1 (0x1)
> >        Signature Algorithm: sha1WithRSAEncryption
> >        Issuer: C=US, O=Organization Name.00000001, CN=Issuer
> > Name/emailAddress=email@issuer_name.com
> >        Validity
> >            Not Before: Jan  1 12:00:00 0 GMT
> >            Not After : Dec 31 12:00:00 9999 GMT
> >        Subject: C=US, O=Organization Name.00000001, CN=Issuer
> > Name/emailAddress=email@issuer_name.com
> >        Subject Public Key Info:
> >            Public Key Algorithm: rsaEncryption
> >            RSA Public Key: (1024 bit)
> >                Modulus (1024 bit):
> >                    00:b8:c3:5c:86:57:56:a7:67:da:dd:65:7c:06:4c:
> >                    eb:e2:98:6e:88:db:e2:f0:4d:ff:ec:c0:99:70:2f:
> >                    a1:42:1f:ca:01:9e:97:c6:ec:ca:35:3c:57:77:53:
> >                    4b:bd:2d:12:08:24:84:36:4a:1a:9b:10:27:07:f5:
> >                    c3:a2:d8:44:f9:76:37:7d:b1:f4:4c:d5:24:4e:53:
> >                    ff:75:5c:b4:be:49:83:5b:af:8d:3c:57:87:e6:93:
> >                    61:5e:df:30:30:74:72:6d:2d:5e:c5:46:58:c9:22:
> >                    4c:57:1a:08:ff:a5:3a:c3:b1:9b:fe:f5:44:a7:f8:
> >                    c2:d5:d0:40:c8:c8:5e:7f:59
> >                Exponent: 65537 (0x10001)
> >        X509v3 extensions:
> >            X509v3 Subject Key Identifier:
> >                2F:71:BC:8F:B4:E5:67:C2:35:C4:57:EF:72:35:25:97:D0:6C:8A:D9
> >            X509v3 Authority Key Identifier:
> >                DirName:/C=US/O=Organization Name.00000001/CN=Issuer
> > Name/emailAddress=email@issuer_name.com
> >                serial:01
> >
> >            X509v3 Basic Constraints:
> >                CA:TRUE
> >            X509v3 Key Usage:
> >                Certificate Sign
> >            X509v3 Subject Alternative Name:
> >                email:email@issuer_name.com
> >            X509v3 Issuer Alternative Name:
> >                email:email@issuer_name.com
> >    Signature Algorithm: sha1WithRSAEncryption
> >        6a:8e:f0:82:55:50:66:c7:5b:ff:bb:ba:84:eb:b1:70:46:c1:
> >        a9:98:8e:db:0d:05:b2:01:da:e9:b3:2a:95:7c:46:95:94:b1:
> >        26:47:05:4d:1e:97:d9:72:fc:dd:b0:e5:48:ff:97:cc:39:13:
> >        5c:65:9e:dd:7d:c9:fa:ff:a1:e8:30:23:6a:1a:47:13:f8:01:
> >        36:29:ac:35:f7:bf:ac:0c:86:cc:80:d6:4c:27:9d:dd:65:93:
> >        ba:96:68:4f:0d:c8:61:54:16:00:1f:b6:56:c2:e4:4c:80:82:
> >        49:2f:eb:01:31:2f:0a:68:c8:1e:c8:8e:d9:28:3d:4d:d6:17:
> >        98:e5
> > -----BEGIN CERTIFICATE-----
> > MIIDXTCCAsagAwIBAgIBATANBgkqhkiG9w0BAQUFADBuMQswCQYDVQQGDAJVUzEj
> > MCEGA1UECgwaT3JnYW5pemF0aW9uIE5hbWUuMDAwMDAwMDExFDASBgNVBAMMC0lz
> > c3VlciBOYW1lMSQwIgYJKoZIhvcNAQkBDBVlbWFpbEBpc3N1ZXJfbmFtZS5jb20w
> > IhgPMDAwMDAxMDExMjAwMDBaGA85OTk5MTIzMTEyMDAwMFowbjELMAkGA1UEBgwC
> > VVMxIzAhBgNVBAoMGk9yZ2FuaXphdGlvbiBOYW1lLjAwMDAwMDAxMRQwEgYDVQQD
> > DAtJc3N1ZXIgTmFtZTEkMCIGCSqGSIb3DQEJAQwVZW1haWxAaXNzdWVyX25hbWUu
> > Y29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC4w1yGV1anZ9rdZXwGTOvi
> > mG6I2+LwTf/swJlwL6FCH8oBnpfG7Mo1PFd3U0u9LRIIJIQ2ShqbECcH9cOi2ET5
> > djd9sfRM1SROU/91XLS+SYNbr408V4fmk2Fe3zAwdHJtLV7FRljJIkxXGgj/pTrD
> > sZv+9USn+MLV0EDIyF5/WQIDAQABo4IBBTCCAQEwHQYDVR0OBBYEFC9xvI+05WfC
> > NcRX73I1JZfQbIrZMIGABgNVHSMEeTB3oXKkcDBuMQswCQYDVQQGDAJVUzEjMCEG
> > A1UECgwaT3JnYW5pemF0aW9uIE5hbWUuMDAwMDAwMDExFDASBgNVBAMMC0lzc3Vl
> > ciBOYW1lMSQwIgYJKoZIhvcNAQkBDBVlbWFpbEBpc3N1ZXJfbmFtZS5jb22CAQEw
> > DAYDVR0TBAUwAwEB/zALBgNVHQ8EBAMCAgQwIAYDVR0RBBkwF4EVZW1haWxAaXNz
> > dWVyX25hbWUuY29tMCAGA1UdEgQZMBeBFWVtYWlsQGlzc3Vlcl9uYW1lLmNvbTAN
> > BgkqhkiG9w0BAQUFAAOBgQBqjvCCVVBmx1v/u7qE67FwRsGpmI7bDQWyAdrpsyqV
> > fEaVlLEmRwVNHpfZcvzdsOVI/5fMORNcZZ7dfcn6/6HoMCNqGkcT+AE2Kaw197+s
> > DIbMgNZMJ53dZZO6lmhPDchhVBYAH7ZWwuRMgIJJL+sBMS8KaMgeyI7ZKD1N1heY
> > 5Q==
> > -----END CERTIFICATE-----
> >
> >
> > "Joe Kaplan" wrote:
> >
> >> Perhaps you could post the PEM format of one of the offending certs so
> >> that
> >> people could look at it?
> >>
> >> However, I'd also suggest that if Windows chokes on a cert with one of
> >> these
> >> dates that you just avoid using such old not-before dates.  It is hard to
> >> imagine why you'd need a cert with a validity that precedes the actual
> >> invention of x509 certs in general.
> >>
> >> --
> >> Joe Kaplan-MS MVP Directory Services Programming
> >> Co-author of "The .NET Developer's Guide to Directory Services
> >> Programming"
> >> http://www.directoryprogramming.net
> >> "jcm" <j**@discussions.microsoft.com> wrote in message
> >> news:A0FE3605-8104-4B27-8897-F96E8CC3D2D9@microsoft.com...
> >> >I have to import a public key certificate file (.cer) to verify a
> >> >signature.
> >> > If the certificate has a generalizedTime notBefore element with a date
> >> > prior
> >> > to 1 Jan 1601, I get the error "Cannot find the requested object".
> >> > Manually
> >> > editing the cert to have the later date will at least allow loading of
> >> > the
> >> > certificate. This happens even in the Certificates Add-in for MMC (not
> >> > the
> >> > same error, just a very generic failure, but it seems like the same
> >> > problem).
> >> >
> >> > It fails doing somethnig as simple as this:
> >> >
> >> > X509Certificate2 certificate = new X509Certificate2(certFile);
> >> >
> >> > The same certificate (with a date prior to year 1601, even 0000) will
> >> > load
> >> > using Java apis.
> >> >
> >> > So is this a bug in the Windows security apis? I have a third party
> >> > tool
> >> > that has generated existing certificates that I need to use, but can't
> >> > because of this limitation.
> >> >
> >> > --
> >> > Joe
> >>
> >>
>
>