none
ADWS Event ID 1400

    คำถาม

  • In my Windows Server 2008 R2 in the Event Viewer there is an error pertains as ADWS Event ID 1400 states-(Active Directory Web Services could not find a server certificate with the specified certificate name.A certificate is required to use SSL/TLS connections.To use SSL/TLS connections,varify that a valid server authentication certificate from a trusted certificate Authority (CA) is installed on the machine.

    Certificate Name:WIN-BNILITE1545.mumthaz.contoso.com ). What is this error? And What is the remedy for this error?


    MumthazMuhsin
    19 ตุลาคม 2554 13:43

คำตอบ

  • Hi,

     

    Please refer to the following Microsoft TechNet blog and you will read the following sentence.

     

    Only if you:

     

    1. You think you have a valid Server Authentication certificate.

    2. Want to use SSL to connect to ADWS.

     

    By default Windows Server 2008 R2 DC’s will log this warning until they get issued a valid server certificate (which you get for free once you deploy an MS Enterprise PKI, by getting a Domain Controller certificate through auto-enrollment). Once that happens you will log a 1401 and never see this warning again.

     

    If you think you have the right certificate (and in this case, the customer thought he did - it had EKU of Server Authentication (1.3.6.1.5.5.7.3.1), the right SAN, and chained fine), compare it to a valid DC certificate issued by an MS CA. You can do all this in a test lab even if you’re not using our PKI by just creating a default PKI “next next next” style and examining an exported DC certificate. When we compared the exported certificates, we found that his 3rd-party issued cert was missing a Subject entry, unlike my own. We theorized that this might be it – the subject is not required for a cert to be valid, but any application can decide it’s important and it’s likely ADWS does.

     

    Friday Mail Sack: Mostly Edge Case Edition

    http://blogs.technet.com/b/askds/archive/2010/08/13/friday-mail-sack-mostly-edge-case-edition.aspx#adws

     

    Regards,


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    22 ตุลาคม 2554 4:58
    ผู้ดูแล

ตอบทั้งหมด

  • This relates to the another error that you have advertize in this forum 

    http://social.technet.microsoft.com/Forums/en-US/winservergen/thread/37393151-2bce-4d3e-9249-3df0b5b0b001/#dbae4341-5b6d-413a-8d02-0e43681d5793.

    Please solve this problem globally. Separating errors may delay problem resolution. 

    Regards

    Milos

    19 ตุลาคม 2554 19:27
  • Hi,

     

    Please refer to the following Microsoft TechNet blog and you will read the following sentence.

     

    Only if you:

     

    1. You think you have a valid Server Authentication certificate.

    2. Want to use SSL to connect to ADWS.

     

    By default Windows Server 2008 R2 DC’s will log this warning until they get issued a valid server certificate (which you get for free once you deploy an MS Enterprise PKI, by getting a Domain Controller certificate through auto-enrollment). Once that happens you will log a 1401 and never see this warning again.

     

    If you think you have the right certificate (and in this case, the customer thought he did - it had EKU of Server Authentication (1.3.6.1.5.5.7.3.1), the right SAN, and chained fine), compare it to a valid DC certificate issued by an MS CA. You can do all this in a test lab even if you’re not using our PKI by just creating a default PKI “next next next” style and examining an exported DC certificate. When we compared the exported certificates, we found that his 3rd-party issued cert was missing a Subject entry, unlike my own. We theorized that this might be it – the subject is not required for a cert to be valid, but any application can decide it’s important and it’s likely ADWS does.

     

    Friday Mail Sack: Mostly Edge Case Edition

    http://blogs.technet.com/b/askds/archive/2010/08/13/friday-mail-sack-mostly-edge-case-edition.aspx#adws

     

    Regards,


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    22 ตุลาคม 2554 4:58
    ผู้ดูแล
  • You should edit the domain controller authentication template and on the subject name tab put the subject name format from none to DNS name.

    Re-enroll the certificate on the domain controller, delete the old certificate and restart ADWS to check if the error is recurring.

    • แก้ไขโดย Bazvv 31 พฤษภาคม 2559 12:58
    • เสนอเป็นคำตอบโดย Andreas Kron 22 พฤศจิกายน 2559 13:46
    31 พฤษภาคม 2559 12:57
  • i only used 6 hours for trying to resolve this issue, and clicked every google hit i could find. there exist so many misleading information. but ended up finding the solution myself.

    for replicating the issue and fixing, its enough to just restart the ADWS service where it would show if you did fix it correctly.

    what i did, was to make a dedicated server with CA and gave the FQDN for the CA wizard, instead of the CA-name. as its not recommended to install a CA on the domain controller. Still i think it would work fine, and don't think this was my root cause

    the i used the default templates, and change the subject to use DNS as it described in many articles.

    The part that really did the trick for me was to only have two certificate to auto enroll. the Kerberos one and Domain Controller Autentiaction.

    The Default had a certificate also called Domain Controller. and this was messing up the event log. deleting that from the template, everything start working. my recommendation is to only have one certificate with the feature "Client and Server Authentication" remove all other like kerberos and the domain controller certificate. as soon i have more then one, the issue starts comming

    some threads was saying it was possible to test with LDP.exe on port 636, but that is not true, without cert this will still work, and also telnet to this port. and i experienced that all certificeres was enrolled and valid. so it was hard to troubleshoot, even by i could see the certificate name existed.

    another wrong information is that Microsoft is saying a restart is required for this to work. Just restarting the ADWS service is enough.



    Danny Nilsson


    • เสนอเป็นคำตอบโดย Mooock 14 มิถุนายน 2561 12:30
    • แก้ไขโดย Mooock 14 มิถุนายน 2561 13:02
    14 มิถุนายน 2561 12:30