Can't import x.509: Cannot find the requested object
jcm
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
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...@microsoft.com...
jcm
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
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...@microsoft.com...
jcm
seems to choke on anything prior to year 1601, but the Gregorian calendar
mentioned in the spec referred to by the x.509 spec starts at 1582. Close
enough, I guess. But the spec doesn't have any limit related to either of
those dates.
Anyway, thanks for the reality check. I'll escalate to MS.
--
Joe