PKIVIEW giving false alarms?
Rich Raffenetti
secure (SSL/https) web site? I can give more details about our PKI if
needed.
We can navigate to the web site with a browser and access the .CRT and .CRL
files located there. At the same time PKIVIEW says there is a problem with
those elements.
The web site contains secondary locations for the AIA and CDP elements of
our issuing CA. The primary location is Active Directory.
We have been running this way for over two years and have no problems with
our PKI except for what PKIVIEW displays. It's disconcerting!
Paul Adare
microsoft.public.security.crypto news group, Rich Raffenetti
<raffe...@comcast.net> says...
Not sure about PKIVIEW, but CDP and AIA locations should never be
hosted on SSL sites. You potentially setup chicken and egg problems
doing so. How does one verify the revocation status of the SSL
certificate if one can't get to the CRL until the revocation status of
the SSL certificate is checked first? See the problem?
--
Paul Adare - MVP Virtual Machines
It all began with Adam. He was the first man to tell a joke--or a lie.
How lucky Adam was. He knew when he said a good thing, nobody had said
it before. Adam was not alone in the Garden of Eden, however, and does
not deserve all the credit; much is due to Eve, the first woman, and
Satan, the first consultant." - Mark Twain
Rich Raffenetti
"Paul Adare" <pad...@newsguy.com> wrote in message
news:MPG.1f4503b2a...@msnews.microsoft.com...
Interesting point. I never thought about that. The reason is that, in our
case, the SSL certificate for the web site is from an external service
(Entrust.net Secure Server Certification Authority) and our Microsoft PKI
does not depend on the external service. I suspect therefore, that in our
situation, the issue you describe does not exist. Do you agree?
Our web site is IIS6 and the PKI is all Windows Server 2003 Standard and
Enterprise (offline CA and issuing CA respectively).
Paul Adare
Yes, if you're using a different PKI hierarchy for your SSL cert then
you won't hit this problem, though I have to ask what the point of
using SSL on your CDP and AIA location is in the first place. The
information stored there is, by definition, public information. What
threat are you trying to mitigate against? I think that if you examine
this you'll find that you really don't need the SSL cert.
Rich Raffenetti
with SSL that we could use for the folder containing the CDP and AIA files.
To the internet, only port 443 is open. It seemed like a good place to
place the files. I don't think it was a bad choice. Maybe the PKIVIEW
result says that it was a bad choice. Or maybe PKIVIEW is wrong. Which
brings us back to the original question...
Suppose on the web site I remove the requirement for SSL on the folder
containing the files. Is it an easy matter to change the AIA and CDP
locations for newly issued certs? The only change would be https --> http.
And, https would also be usable so as not to make existing certs wrong.
My schedule says I'm soon to issue a new CRL from the root CA. This might
be an appropriate time to make such a change.
Brian Komar
support for any SSL protected URLs in chain building. Likewise, you can no longer use FTP
URLs.
Please see the update revocation checking whitepaper for more details
http://www.microsoft.com/technet/prodtechnol/winxppro/support/tshtcrl.mspx
Brian
Rich Raffenetti
"Brian Komar" <bko...@nospam.identit.ca> wrote in message
news:MPG.1f4667cf4...@msnews.microsoft.com...
I have changed the web site so that the folder containing the AIA and CDP
objects does not require SSL. However, the AIA and CDP references still
contain URLs with https. Will it be difficult to change that?
Rich
Brian Komar
raffe...@comcast.net says...
cannot edit an issued certificate as it is a signed object.
Brian
Rich Raffenetti
Thanks. I need to understand this better.
In order to effect the web site URL change described above, I need to edit
the two registry items in the Root CA that point to the CDP and AIA
locations. This is easy.
The root CA issues two items, the CRL and the cert for the issuing CA. In
order to make the above change effective, then I need to issue a new CRL and
a new cert for the issuing CA. I expect that the new CRL will not cause any
certs from the issuing CA to have to be reissued. What I don't appreciate
is whether or not issuing a new cert for the issuing CA will force every
cert already issued by the issuing CA to have to be reissued.
Again I wouldn't expect that all my currently issued certs would fail if
they aren't invalid but I still wonder if the above action invalidates them?
Thanks again for your attention to this issue.
Rich Raffenetti
"Rich Raffenetti" <raffe...@comcast.net> wrote in message
news:%23CECRQF...@TK2MSFTNGP04.phx.gbl...
disappeared as expected. I'll be looking at the question of whether or not
certs issued by the Issuing CA are invalidated or not. Both issuing CA
certs are in the store and both are not expired.
Rich Raffenetti
new cert for the issuing CA. I took the option of renewing while using the
same keys.
Interestingly enough, the cert chain (for certs that were issued prior to
installing the renewed cert) includes the renewed cert.
Does all of this seem right? Am I missing something? I need to confirm
that it is working right before I do the same thing in my production
network.
Martin Rublik
I'm interrested in this one too. Is it because the old certificate is
still accessible through LDAP and it is still in trusted store? If it
were removed and the new one would be published (with a same public key)
will it match through Subject Key Identifier (as described in part Chain
Building | Key Match in article Troubleshooting Certificate Status and
Revocation
http://www.microsoft.com/technet/security/topics/cryptographyetc/tshtcrl.mspx)
?
>
> Interestingly enough, the cert chain (for certs that were issued prior to
> installing the renewed cert) includes the renewed cert.
Is this because of the key match described earlier?
>
> Does all of this seem right? Am I missing something? I need to confirm
> that it is working right before I do the same thing in my production
> network.
>
I think there is one more issue to consider. If you stop publishing CRLs
to old CDPs (https), clients won't be able to check revocation status of
already issued certificates if they cannot reach LDAP, e.g. if you're
using certificates in place where your domain controllers aren't
reachable you won't be able to check for CRLs that could be accessible
through removed CDPs.
Regards
Martin Rublik