|
Hi Joseph, The thing with the GUID is that DCs use
the GUIDs to locate and identify each other; hence a cert without a GUID would
break the replication, so it’s quite natural that the cert was rejected
by the DC (good to know that certs that can break things are rejected) I was too trying to edit the inf file
directly and was failing. Just skipped that and used certreq with arguments.
Cool that you managed to figure out that part. Guy From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Isenhour, Joseph I think I may have figured it out. I
was able to repro this on my Microsoft CA. The certificate will not load
unless you provide a valid host name and GUID in the SAN. In my case I
also added my alias. Guy, I know you said to include the GUID so
shame on me for not listening. It appears you also need to include the DC
host name, even if the host name appears in the subject which is in contrast to
the Microsoft documentation which states that the host name can be in the
subject OR the SAN. I haven't tried this out with our external
CA yet but I'm thinking it's going to work this time. Crossing my
fingers. From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Isenhour, Joseph After a lot of time spent testing I
finally figured out how to make this work with an external CA. The main
issue is that the third party CA does not allow you to use the certreq.exe
utility to submit the request. Instead I had to paste the CSR directly
into their web form which meant that I needed to include all extensions in
the .inf file the reqDCcert.vbs creates. I found out the hard way that
you can't simply add these extensions to the .inf. The data has to be
converted and encoded. In the end I had to modify reqDCcert.vbs in the
following way: aASNsubstring(0, ASCIIDATA) = sDNShostname ' ' This is the section I added. I'm
basically adding a second DNS name to the INF file. ' I'm adding it here in the script instead of
the .INF file because it needs to be converted. ' aASNsubstring(1, ASCIIDATA)
= "ldap.company.net" sASN = sASN & aASNsubstring(1, HEX_TYPE) & _ I basically added another section that
added a second DNS name. I also commented out the GUID because I did not
need it. It may be possible to uncomment it. Now run the reqDCcerts.vbs to create the
.inf file. Then run: certreq -new
servername.inf yourNewRequest.csr Now you can paste the contents of
yourNewRequest.csr directly into the third party request form. Now for the bad news. After all of
that it still doesn't work! :-) It added the SAN to my cert; however, I
still can't use ldp.exe to connect using the LDAPS when I use the alternate
name. The alternate name shows up just as it did when I used the
Microsoft CA; however, when I used the Microsoft CA LDAPS worked. Now it
doesn't I'm going to keep at it. I let
everyone know If I get it to work. From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Have never tried that and do not have the
environment handy to give it a shot, but as long as you meet the requirement
for the DC’s cert and the CSR contains the desired SANs, you should be
fine. Just make sure that DCs GUID, FQDN and the alias are in the SAN. Not sure
if you will need to specify the template – have no idea if 3rd
party CA will reject the CSR or just ignore that part. Guy From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Isenhour, Joseph Thanks Guy. That is a really helpful
blog. After a little fuss I was able to get the cert to recognize and
honor the Subject Alternative Name using your steps. Do you know if these
same steps will work against a third party CA? In any case I plan on
trying it out on a third party CA tomorrow. I'll let you know how it
goes. From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of It turned out to be a bit more complicated
than I thought… I made some notes over here: http://guy.netguru.co.il/archives/18-Issuing-certificates-to-DCs-with-additional-DNS-names.html I have not yet verified that LDAPS works
with aliases when querying, but the cert installs fine and in theory has all
the requirements… If you want to automate the process, you
will probably want to tweak reqdccert.vbs to generate valid
“Subject” in the [NewRequest] section. At least should give you a direction. Guy From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Isenhour, Joseph Thanks Guy, I've spent about 12hours trying to write a
script that will include the Subject Alternative Name in the CSR. I found
the ICEnroll COM interface on MSDN and am using it to generate my
request. The request works fine; however, the Subject Alternative Name
never seems to take when I request the cert. Here's what I added to my script: Call Request.addExtensionToRequest(True,
"2.5.29.17", "ldap.company.net") The call goes through without generating
an error; however, it doesn't seem to take. Has anyone out there successfully created
a CSR using this extension? From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of You will need to issue new certificates to
the DCs with the ldap.company.net in the Subject Alternative Name section. The
certificate requirements for DCs are specified in the following KB: http://support.microsoft.com/default.aspx?scid=kb;en-us;Q291010 Though it is about 3rd part
CAs, the requirements still apply even if you are using MS CA. The key point is
that the certificate can not be issued to an alias (ldap.company.com) in the
Subject field – the alias should be part of the Alternative Name together
with DCs GUID. Guy From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Isenhour, Joseph We currently
provide LDAPS to our customers. Right now the certificates that we load
on our DC uses the DC name and the clients connect using that name. We'd
like to set up a DNS alias like: ldap.company.net. I tried generating a
cert named ldap.company.net and loaded it on a DC; however, the clients were
unable to connect. Does
anyone know if MS has a restriction that will not allow a cert to be loaded for
LDAPS if the name on the cert is not the same as the DC? Thanks
|
Title: LDAPS question
