Non-domain computer request certificate

We have Enterprise CA with Certificate Enrollment Policy Web Service and Certificate Enrollment Web Service on same domain computer.
When I configure Enrollment policy on non-domain computers by adding exist Certificate Enrollment Policy Server:
mmc->Certificates(local computer)->Personal-Manage Enrollment Policy, all looks fine. But when I do request
New Certificate -> Select Certificate Enrollment Policy appears window with empty list and message:
Certificate types are not available.You cannot request a certificate at this time because no certificate types are available. From domain computers all works fine, I can choose templates from the list and can do command:
certutil -config "DomainComp\CAname" -ping.
from non-domain computers I can't do certutil -ping:
...Connecting to DomainComp\CAname ...
Server could not be reached: The RPC server is unavailable. 0x800706ba

I'm used select username/password authentication when installed CES/CEP roles. If I want to use authentication with
certificates, I must to make request and enroll it on CA. This is a problem for non-domain computer. By the way, using method:
http://social.technet.microsoft.com/Forums/windowsserver/en-US/098f858a-3e89-48d2-828e-274487033f6b/how-to-request-certificate-from-a-nondomain-computer?forum=winserversecurity
I can manually make request file, issue it on Enterprise CA and export certificate file, when import certificate.
This method
http://blogs.technet.com/b/askds/archive/2010/05/25/enabling-cep-and-ces-for-enrolling-non-domain-joined-computers-for-certificates.aspx not work because appears empty list of enrolment templates.

Similar Messages

Non-domain computer cannot connect to server

I have a unique issue.
I have a Windows 2008 server running Exchange 2010 (all roles on single server )
I have a Windows 7 Pro client that is not a member of the domain.
When setting up Outlook 2010 I enter user's name, email address and password. The system starts configuring, it successfully searches for [email protected] settings. It then prompts for credentials. I cannot get it to take them.
However, If I user the domain admin account I can successfully setup the domain admin email in Outlook. I just cannot do it with a standard user.
Also, I noticed that this non-domain computer can access domain member server if I provide credentials (domain\username). This does not work with this or any of my other Windows 2008 servers.
I have been fighting this with no relief in sight...
Thanks
Wayne

Let me be clear about my symptoms.
Exchange with domain joined computers autodiscover/Outlookworks fine....
DC's and exchange server all have same time/date otherwise nobody would be able to authenticate.
The problem only exists with non-domain computers (both within the network and outside of the network)
The autodiscover tests fine with exchange connectivity tester. I cannot test outlook as I have a certificate from an untrusted root that is installed manually on the non-domain computers.
The non-domain computers can connect to windows 2003 member server (with appropriate domain credentials) but not to this 2008 (or the other 2 2008 member servers)
Update- If I configure the domain administrator account on that same non-domain connected machine, it retrieves the domain admin email just fine.....

How to request certificate from a non-domain computer

We using a Windows Server 2008 R2 Enterprise CA to issuing webserver-certificates (SSL). The CA-Server is a member of a AD-Domain and online. Now we want to request certificates from computers like Windows Server 2008 R2 or Linux Server which aren't member
of the domain.
How we can request certificates automatically with a script remote from these Windows Servers, for example ? Is it possible to use the "Certificate Enrollment Web Service" without the "Certificate Enrollment Policy Web Service" ?
Is it possible to use certreq in this scenario ?
Thanks for your help.

Now I have found a solution. Shortly I want describe the way:
Prerequirements:
1. ADCS Enterprise Certification Authority is installed
2. ADCS Certificate Enrollment Web Service is installed on a server
3. ADCS Certificate Enrollment Policy Web Service is installed on an other server
Steps to do:
1. Prepare a request-file for a certificate
2. On a computer which is not a member of the Domain/Forest of the CA-Service: submit the request to the CA and receive the issued certificate. The following command have to written in one line without line breaks.
certreq -submit
    -Username {domain}\{username}
    -p {password}
    -PolicyServer "https://{FQDN CertificateEnrollmentPolicyWebService-Server/-Alias}/ADPolicyProvider_CEP_UsernamePassword/service.svc/CEP"
    -config "https://{FQDN CertificateEnrollentWebService-Server/-Alias}/{CAName}_CES_UsernamePassword/service.svc/CES"
    -attrib "CertificateTemplate:{TemplateName}"
    {Enter Path and Name of the Request-File}
    {Choose Path and Filename for certificate}
   Sample:
   certreq -submit
        -Username contoso\Serviceaccount
        -p P@ssw0rd
        -PolicyServer "https://CAPolicyEnroll.contoso.com/ADPolicyProvider_CEP_UsernamePassword/service.svc/CEP"
        -config "https://CAWebEnroll.contoso.com/IssuingCA1_CES_UsernamePassword/service.svc/CES"
        -attrib "CertificateTemplate:MyOwnSSLTemplate"
        request.req
        sslcert.cer
3. Now you can find a file with your requested certificate locally in path you have choosen for the certificate-file.
I hope this will be helpful for other people enrolling certificates on non-domain member computers.

Non-domain computer WSUS entries keep getting reset

We have a non-domain member laptop. So it does not get domain GPOs, confirmed by RSOP. Somewhere along the line someone entered the wrong WSUS server into gpedit.msc for the WUSERVER and WUSTATUSSERVER: http://server02:80. Whenver I try to change it to
the correct server (http://server01:8530) using gpedit.msc, something changes it back to server02. I searched the entire registry and can't find where it's set other than the standard WUSERVER and WUSTATUSSERVER locations. Where else could this value be stored
and how to I get this laptop to check in with the proper WSUS server?
Ben JohnsonWY

We have a non-domain member laptop. So it does not get domain GPOs, confirmed by RSOP.
Don't really need RSOP to confirm that a non-domain member laptop isn't getting domain GPOs, since it's functionally impossible for that to happen.
Somewhere along the line someone entered the wrong WSUS server into gpedit.msc for the WUSERVER and WUSTATUSSERVER: http://server02:80. Whenver I try to change it to the correct server (http://server01:8530) using gpedit.msc, something changes it
back to server02.
Well... now... here we have another functional impossibility. The *only* thing that can edit Local Policy on a computer is a human being working from the Local Policy Editor on that computer. In fact, not even a Group Policy Object (GPO) can change a value
in the Local Policy configuration settings!
The Good News, though, is that the Windows Update Agent is policy aware, so IF something is changing Local Policy, specifically the URL of the WSUS Server, the Policy Change Event will be logged in the WindowsUpdate.log, and from that you can determine exactly
*WHEN* the change is being made. Knowing when the change is being made will likely help narrow down
who or what (although there's not much opportunity for a "what" in this instance) is making that policy change.
I searched the entire registry and can't find where it's set other than the standard WUSERVER and WUSTATUSSERVER locations.
That's it. But this logic seems to suggest you have inverted cause and effect. The registry values are set by the Local Policy settings, not the other way around.
how to I get this laptop to check in with the proper WSUS server?
Well, this part is easy. You fix the Local Policy problem. :-)
Lawrence Garvin, M.S., MCSA, MCITP:EA, MCDBA
SolarWinds Head Geek
Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2014)
My MVP Profile: http://mvp.microsoft.com/en-us/mvp/Lawrence%20R%20Garvin-32101
http://www.solarwinds.com/gotmicrosoft
The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

Domain computer can't use or ping hostname of non-domain computer

In my case I need to work with computers on different domains and workgroups. My XP machine works properly. My Windows 7 Enterprise x64 machine didn't have an issue until I brought it into a domain. At that point I could not longer
ping or RDP by hostname. After tracking it down it appears the all hostnames are appended with "whateverdomain.com".
After researching some articles I focused on the registry setting "Computer\HKLM\System\CurrentControlSet\services\Tcpip\Parameters". Under parameters is an entry for Domain that has the value "whateverdomain.com". If I blank this value and then
release/renew the DHCP - everthing works as expected. Upon reboot this entry is re-inserted and the problem returns.
It's as if the order for name resolution gets messed up once you join your computer to a domain and it skips the first step. Instead of first trying "hostname" against the DNS it goes straight to "hostname.whateverdomain.com".
Also, If I bring up the VHD of the machine before joining the domain it works as expected.

hmmm. If your computer is on a domain, and you plug it into someone else's network running workgroup, you should be OK, if the workgroup is on single segment. Your computer will resort to Netbios name resolution if host name resolution fails.
You can remove the primary dns suffix from your computer, but if the DHCP server that negotiates the lease on the network you are on supplies option 015, it will add the domain suffix to that NIC.
Since I do not know the exact situation you are facing, you can try this...
Open the control panel--> system--> advanced settings --computer name tab --> change button --> more button --> uncheck "change primary dns suffix... & also clear the text box that contains the primary dns suffix.
Overview regarding name resolution for windows:
Microsoft Windows TCP/IP NetBIOS and Host Name Resolution
http://www.anitkb.com/2010/08/microsoft-windows-tcpip-netbios-and.html
Visit: anITKB.com, an IT Knowledge Base.

Non Domain Computer users how to AD RMS service ?? I completed registry setting.

hi all
I'm having problems with AD RMS.
Domain members computer is operating normally.
But
WORKGROUP computer is not able to connect to the AD RMS server.
AD RMS Cluster to ping is successful.
client registry settings are now complete.
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSDRM\ServiceLocation\Activation]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSDRM\ServiceLocation\EnterprisePublishing]
HKLM\Software\Microsoft\Office\14.0\Common\DRM
CorpLicenseServer
REG_SZ
https://rms. example.com/_wmcs/licensing
HKLM\Software\Microsoft\Office\14.0\Common\DRM
CorpCertificationServer
REG_SZ
https://rms. example.com/_wmcs/certification
HKCU\Software\Microsoft\Office\14.0\Common\DRM
AdminTemplatePath
REG_EXPAND_SZ
%localappdata%\Microsoft\DRM\Templates
HKCU\Software\Microsoft\Office\14.0\Common\DRM
DisablePassportCertification
REG_DWORD
1
used in the office, the following message will appear.
"This service is temporarily unavailable. Ensure that you have connectivity to this server. This error could be because you are working offline, your proxy settings are preventing your connection, or you are experiencing intermittent network issues."
How do I connect to a WORKGROUP normally?

Hi,
this is definately the right direction. Can access https://rms. example.com?
Can you see the default IIS page?
Check out this article as well and verify for example if you have a 64bit Office. - http://blogs.technet.com/b/rmssupp/archive/2007/07/13/rms-testing-rms-without-modifying-the-ad.aspx
Regards,
Lutz

Non-domain machines cannot launch RemoteAPP

Hi.
I have Server 1 with RDS WEB and RD Gateway Role. And I have Server 2 with RDS Host, License Manager, RemoteApp installed and they are in collection.
For test: I installed certificate of Enterprise CA on non-domain computer and now it connects successfully to RDS Web service (globalDNSname.mycompany.com). Non-Domain computers login to RDWeb well (certificate is good). But when I launch RemoteApp it asks
me credentials and write that logon is unsuccessfull.
It works with domain computers and asks no credentials. Certificate is isssued to globalDNSname.mycompany.com.
Could you help me?

Hi,
Can you open successful connection of RemoteApp on domain joined system?
The PC which is no-domain joined is on same LAN. Might possible that DNS or Hostname of server can’t resolve the name correctly from non-domain joined system. Please see whether you can directly ping or get successful connection to the server from non-domain
joined system.
Apart there are certain point list which need to make sure before successful connection. Check whether you have correctly configured RD CAP and RD RAP policy. When you create the RD RAP, add the user groups that you defined in the RD CAP. Also, create a new
RD Gateway-managed computer group that contains both the NetBIOS names and the fully qualified domain names (FQDNs) of the RD Session Host servers or the RD Session Host server farm that hosts the RemoteApp programs.
For more details you can check beneath article.
Checklist: Make RemoteApp Programs Available from the Internet
https://technet.microsoft.com/en-in/library/cc772415.aspx
Hope it helps!
Thanks.
Dharmesh Solanki
Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Support, contact [email protected]

Use Wildcard SSL Cert to Monitor Non-Domain COmputers

Hello,
I was wondering if a Wildcard SSL Cert from GoDaddy or another Provider can be used to monitor Non-Domain Computer on SCOM 2012R2?
TIA,
Jim

Hi,
The Operations Manager agents support two types of authentication method, Kerberos or certificate based authentication. In order to monitor servers and clients located outside the Operations Manager’s native Active Directory domain, you will need to configure
certificate authentication using either an internal Certificate Authority or through a 3rd party Certificate Authority.
Regards,
Yan Li
Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact [email protected]

PEAP authentication for domain & non-domain computers

Hello Everyone,
Some of our users have laptops that are not in the domain and are unable to connect to the wireless network. Although their computers aren't in the domain, the users do have an AD account and are currently a part of the security group attached to the Wireless NPS policy. The only remedy I have for this problem is to manually add the SSID to their computer which defeats the purpose of this wireless network. The ultimate goal is to allow the user to connect to the wireless network by entering their domain credentials and moving on.
We have a WLC 2504 running 7.4.110.0 with 15 1602i APs. The SSID is configured to pass 802.1x EAP authentication to NPS running on windows 2008 R2. With mobile phones and tablets, the authentication is successful without a hitch so I don't understand why a non-domain computer is unable to connect without manually entering the SSID. In the WLC log, I will see entries such as:
"AAA Authentication Failure for UserName:host/LastNameFirstInitial-LT.mydomain.Local User Type: WLAN USER".
By examining this log entry, to me it says the domain profile on the computer is being sent to the NPS for authentication instead of the username and password. We have a 3rd party SSL certificate installed on the NPS server.
Taking it one step further - We have a second SSID for guest users that is configured with the same setup except that the NPS is configured to accept authentication attempts from a single AD user called "mydomain\guest". We decided on this approach for the guest wireless network so that we can rotate the password automatically every week with a vbscript that manipulates the password via LDAP. Users with laptops in different domains are unable to connect to the guest wireless network and I'm starting to think the machine authentication is a problem.
Any suggestions would be greatly appreciated.
Thanks,
Ali.

Hi Ali,
That’s all part of the wonderful world of wireless on Windows.
When a connection to a WLAN is made on a windows machine, by selecting it from available Wireless Networks list (Passive RF Scan), and Windows as parsed the 802.11 AP Beacon to contain the WPA2, 802.1X element, by default it will attempt to connect with known or active session credentials.
Typically it will be Machine account (they all have them whether on a Domain or not) and then /Or User. This order and preference may change depending on version of Windows (Vista to Windows 8) and service pack level.
Regardless the only thing you can count of for sure is that the first authentication attempt from a windows client will not involve the user entering information. Once the first attempt fails the Windows supplicant will prompt the user for login information via a notification in the system tray, which may or may be noticed by the user. May or may not stay for more than 5 seconds.
Windows XP and Vista were the worst for this. Windows 7 and Windows 8 this process and recovery and user prompt mechanism is greatly improved but not infallible.
The only way to avoid this would be to manually configure the WLAN profile on the windows machine as you are currently doing.
Mobile phones and tablets don’t have this issue as they don’t have issue because software coding in their supplicants. Besides the only “system” credentials on iOS or Android phone are typically your Play Store and App Store accounts, and both vendors know those won’t be accepted for network access by default anywhere.
There isn’t an easy way to support non-domain windows systems on a domain integrated one.
You might want to try adding another SSID.
You could have a corporate SSID, Guest Portal and a third that is PSK + Guest Portal. ON NPS you could filter for RADIUS attribute called-station-id (includes SSID) to allow all domain ID’s access instead of the just that WLAN.
Or you could look at swapping out NPS for a Cisco ISE VM/appliance with the new Plus licenses add lower cost for onboarding devices and Windows XP and up are supported for supplicant configuration via ISE.

SCSM 2012 Portal change from http to https to get silverlight to work on non domain computers?

Hi
Wanting to change our Self Service Portal from http to https and make it accessible from non domain computers.
Non domain computers - the sharpoint parts load (the silverlight does not load). Domain computers can access the portal with no problem.
Does this mean I need to reinstall the portal or can it be changed while in operation now?
Would something like the below link be enough to get https going?
http://blogs.technet.com/b/babulalghule/archive/2013/01/10/how-to-create-alternate-url-for-service-manager-self-service-portal.aspx
Thanks!

the silverlight part not loading due to SSL certification. import the certification into non domain computer will fix this issue.

Log forwarding from a non-domain server certificate types

I'm trying to set up a source initiated subscription (Log forwarding) where the event source server is not in the same domain as the event collector server. I'm following these steps:
https://msdn.microsoft.com/en-us/library/windows/desktop/bb870973(v=vs.85).aspx
It states that for this to work I need the following:
The collector computer should have a server authentication certificate (certificate with a server authentication purpose) in a
local computer certificate store.
And
The source machine should have a client authentication certificate (certificate with a client authentication purpose) in a
local computer certificate store.
I'm looking to use a third party certificate authority to get the 2 above client and server certs. My question is what type of certificates will I need for this to work? As there seem to be a lot of types and I am new to certs.

Hi Chard,
You can just request certificates from Computer Certificate Template. Certificate issued from Computer Certificate Template can be used for both Client and Server authentication.
Here is a related article below for you:
Certificate Templates Overview
https://technet.microsoft.com/en-us/library/cc730826(v=ws.10).aspx
In addition, if you have further query regarding certificates or CA, please refer to security forum below:
https://social.technet.microsoft.com/Forums/windowsserver/en-US/home?forum=winserversecurity
Best Regards,
Amy
Please remember to mark the replies as answers if they help and un-mark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact [email protected]

Premiere and Photoshop CC Crashes at launch on a Domain Non-Domain Admin Computer

On Windows 7 Domain computer lab as a non domain admin but local admin, program launches and then closes with the error codes below. As domain admin account, it works fine. This is a K12 education institution, so giving student's domain admin status is unacceptable. Please advise, any help is greatly appreciated.
FYI, things i have tried:
Integrated graphics cards, I have uninstalled and re-installed drivers. No luck. I have also made the pslog.txt file and given appropriate permissions to all users.
Error Codes:
Windows Error Code - Application error
Faulting application name: Adobe Premiere Pro.exe, version: 8.0.1.21, time stamp: 0x53c7b17f
Faulting module name: dvaui.dll, version: 8.0.1.21, time stamp: 0x53c76970
Exception code: 0xc0000005
Fault offset: 0x00000000002f4e39
Faulting process id: 0xf28
Faulting application start time: 0x01d01a2c32635355
Faulting application path: C:\Program Files\Adobe\Adobe Premiere Pro CC 2014\Adobe Premiere Pro.exe
Faulting module path: C:\Program Files\Adobe\Adobe Premiere Pro CC 2014\dvaui.dll
Report Id: 924f6336-861f-11e4-821e-0024811149b1
Fault bucket 45383478, type 20
Event Name: APPCRASH
Response: Not available
Cab Id: 0
Windows Information - Windows Error
Problem signature:
P1: Adobe Premiere Pro.exe
P2: 8.0.1.21
P3: 53c7b17f
P4: dvaui.dll
P5: 8.0.1.21
P6: 53c76970
P7: c0000005
P8: 00000000002f4e39
P9:
P10:
Attached files:
C:\Users\esdstudent\AppData\Local\Temp\WER9443.tmp.WERInternalMetadata.xml
These files may be available here:
C:\ProgramData\Microsoft\Windows\WER\ReportArchive\AppCrash_Adobe Premiere P_ad637fa2c8bd70d3e74771b4be53569c25a980_00c3bab6
Analysis symbol:
Rechecking for solution: 0
Report Id: 924f6336-861f-11e4-821e-0024811149b1
Report Status: 0

I think you have answered your own question... you must have BOTH types of user accounts set to Administrator
This is an open forum with a mix of program users and Adobe staff, not Adobe support... you need Adobe support
Adobe contact information - http://helpx.adobe.com/contact.html may help
-Select your product and what you need help with
-Click on the blue box "Still need help? Contact us"

Windows Domain Controller certificate for non domain clients

Hi,
Is it possible that we can export windows domain certificate and use it for non domain computers without joining domain, so that they can communicate each others without joining domain controller?
Regards

Hi,
Is it possible that we can export windows domain certificate and use it for non domain computers without joining domain, so that they can communicate each others without joining domain controller?
Not sure that what you want to achieve here.
However, yes, it is possible to export certificates (with private keys) from domain machines then import them to non-domain machines, and some certificates can even function well based on key usages. Please note that Domain Controller certificates are only
meaningful to Domain Controllers. Possession of domain certificates doesn’t indicate machines are part of domain.
Without joining a machine to a domain (or without a trust), the machine is always treated as untrusted by the domain members no matter what kind of certificates it holds.
Best Regards,
Amy
Please remember to mark the replies as answers if they help and un-mark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact [email protected]

Create a certificate for non domain-joined PCs

We have a standard AD domain wit a CA and SharePoint/Exchange servers, hosted internally and externally with TMG 2010 as our firewall. For the external hosting, we have an external certificate from one of the main certificate providers. Internally, our domain-joined
PCs look to the CA to get their trusted certificate from.
This is the issue I am encountering:
Our external users (the ones whose PC is not joined to our domain) are fine when they access our SharePoint and Exchange services externally.
However, when they are connected via VPN, they receive a certificate error and when I look in Certificate > Certification path, I can see that it says:
"DOMAIN NAME" Issuing CA1 > "NAME OF SHAREPOINT WEBSITE".
When such a PC connects to the same website when NOT connected via VPN to the domain, they receive:
"DOMAIN NAME" Root CA > "DOMAIN NAME" Issuing CA1 > "NAME OF SHAREPOINT WEBSITE".
How can I create a certificate for these non-domain joined PCs so that I can import the certificate in the Trusted Root Certification Authorities store? Thank you!

It sounds like the question you are really asking is :
How do I designate the internal root CA as a trusted root CA
Run certutil -addstore root RootCert.crt (this must be run from an administrative command prompt)
This designates the root CA as a trusted root on the client. You also may want to install the intermediate cert to the store (you are not clear on what VPN product you are using, so it may or may not do proper chain building).
Run Certutil -addstore CA IssuingCA.crt
Brian

"Unable to check revocation" error while checking CDP from non-domain user account

Hi!
I use 3-tier PKI infrastructure:
Stand-alone offline Root CA: RootCA;
Stand-alone offline Intermediate subordinate CA: SubCA;
Enterprise CA: EntSubCA.
In certificate we have three CDP point for CRL check:
ldap:///, http:// and file://
I have Windows 2008 R2 server joined to domain.
I use command certutil –verify –urlfetch <filename.cer> >check.txt for revocation checking of certificate.
When I use domain user account for revocation checking, all OK.
I have access to any CDP and all fine.
But when i use local server user account, I haven't access to ldap:/// and process failed although all other links is OK.
My question is "why check fail with non-domain user accout while other CDP point succesfully verifed"?
Here is the logfile from local user:
Issuer:
CN=EntSubCA
DC=DED
DC=ROOT
Subject:
CN=servername.domain_name
Cert Serial Number: 5a896145000300006ee2
dwFlags = CA_VERIFY_FLAGS_ALLOW_UNTRUSTED_ROOT (0x1)
dwFlags = CA_VERIFY_FLAGS_IGNORE_OFFLINE (0x2)
dwFlags = CA_VERIFY_FLAGS_FULL_CHAIN_REVOCATION (0x8)
dwFlags = CA_VERIFY_FLAGS_CONSOLE_TRACE (0x20000000)
dwFlags = CA_VERIFY_FLAGS_DUMP_CHAIN (0x40000000)
ChainFlags = CERT_CHAIN_REVOCATION_CHECK_CHAIN (0x20000000)
HCCE_LOCAL_MACHINE
CERT_CHAIN_POLICY_BASE
-------- CERT_CHAIN_CONTEXT --------
ChainContext.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
ChainContext.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN (0x40)
ChainContext.dwErrorStatus = CERT_TRUST_IS_OFFLINE_REVOCATION (0x1000000)
ChainContext.dwRevocationFreshnessTime: 5 Days, 23 Hours, 15 Minutes, 48 Seconds
SimpleChain.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
SimpleChain.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN (0x40)
SimpleChain.dwErrorStatus = CERT_TRUST_IS_OFFLINE_REVOCATION (0x1000000)
SimpleChain.dwRevocationFreshnessTime: 5 Days, 23 Hours, 15 Minutes, 48 Seconds
CertContext[0][0]: dwInfoStatus=102 dwErrorStatus=1000040
Issuer: CN=EntSubCA, DC=DED, DC=ROOT
NotBefore: 05.02.2015 20:03
NotAfter: 05.02.2016 20:03
Subject: CN=servername.domain_name
Serial: 5a896145000300006ee2
SubjectAltName: DNS Name=servername.domain_name
Template: Machine
70 e4 6b 16 05 a1 62 e3 6d 24 96 ff 44 74 ee a2 3e ce df 18
Element.dwInfoStatus = CERT_TRUST_HAS_KEY_MATCH_ISSUER (0x2)
Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
Element.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN (0x40)
Element.dwErrorStatus = CERT_TRUST_IS_OFFLINE_REVOCATION (0x1000000)
---------------- Certificate AIA ----------------
Failed "AIA" Time: 0
Error retrieving URL: Logon failure: unknown user name or bad password. 0x8007052e (WIN32: 1326)
ldap:///CN=EntSubCA,CN=AIA,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=DED,DC=ROOT?cACertificate?base?objectClass=certificationAuthority
Verified "Certificate (0)" Time: 0
[1.0] file://\\ca\crl\EntSubCA.crt
Verified "Certificate (0)" Time: 4
[2.0] http://webserver/crl/EntSubCA.crt
---------------- Certificate CDP ----------------
Failed "CDP" Time: 0
Error retrieving URL: Logon failure: unknown user name or bad password. 0x8007052e (WIN32: 1326)
ldap:///CN=EntSubCA,CN=ca,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=DED,DC=ROOT?certificateRevocationList?base?objectClass=cRLDistributionPoint
Verified "Base CRL (018d)" Time: 0
[1.0] file://\\ca\crl\EntSubCA.crl
Failed "CDP" Time: 0
Error retrieving URL: Logon failure: unknown user name or bad password. 0x8007052e (WIN32: 1326)
[1.0.0] ldap:///CN=EntSubCA,CN=ca,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=DED,DC=ROOT?deltaRevocationList?base?objectClass=cRLDistributionPoint
Old Base CRL "Delta CRL (018d)" Time: 0
[1.0.1] file://\\ca\crl\EntSubCA.crl
Old Base CRL "Delta CRL (018d)" Time: 4
[1.0.2] http://webserver/crl/EntSubCA.crl
Verified "Base CRL (018d)" Time: 4
[2.0] http://webserver/crl/EntSubCA.crl
Failed "CDP" Time: 0
Error retrieving URL: Logon failure: unknown user name or bad password. 0x8007052e (WIN32: 1326)
[2.0.0] ldap:///CN=EntSubCA,CN=ca,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=DED,DC=ROOT?deltaRevocationList?base?objectClass=cRLDistributionPoint
Old Base CRL "Delta CRL (018d)" Time: 0
[2.0.1] file://\\ca\crl\EntSubCA.crl
Old Base CRL "Delta CRL (018d)" Time: 4
[2.0.2] http://webserver/crl/EntSubCA.crl
---------------- Base CRL CDP ----------------
Failed "CDP" Time: 0
Error retrieving URL: Logon failure: unknown user name or bad password. 0x8007052e (WIN32: 1326)
ldap:///CN=EntSubCA,CN=ca,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=DED,DC=ROOT?deltaRevocationList?base?objectClass=cRLDistributionPoint
OK "Base CRL (018d)" Time: 0
[1.0] file://\\ca\crl\EntSubCA.crl
Failed "CDP" Time: 0
Error retrieving URL: Logon failure: unknown user name or bad password. 0x8007052e (WIN32: 1326)
[1.0.0] ldap:///CN=EntSubCA,CN=ca,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=DED,DC=ROOT?deltaRevocationList?base?objectClass=cRLDistributionPoint
Old Base CRL "Delta CRL (018d)" Time: 0
[1.0.1] file://\\ca\crl\EntSubCA.crl
Old Base CRL "Delta CRL (018d)" Time: 4
[1.0.2] http://webserver/crl/EntSubCA.crl
OK "Base CRL (018d)" Time: 4
[2.0] http://webserver/crl/EntSubCA.crl
Failed "CDP" Time: 0
Error retrieving URL: Logon failure: unknown user name or bad password. 0x8007052e (WIN32: 1326)
[2.0.0] ldap:///CN=EntSubCA,CN=ca,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=DED,DC=ROOT?deltaRevocationList?base?objectClass=cRLDistributionPoint
Old Base CRL "Delta CRL (018d)" Time: 0
[2.0.1] file://\\ca\crl\EntSubCA.crl
Old Base CRL "Delta CRL (018d)" Time: 4
[2.0.2] http://webserver/crl/EntSubCA.crl
---------------- Certificate OCSP ----------------
No URLs "None" Time: 0
CRL 018d:
Issuer: CN=EntSubCA, DC=DED, DC=ROOT
33 af 4d be 0e 35 45 94 bc 8b 3f d9 c1 60 e7 0c c4 83 17 b6
Application[0] = 1.3.6.1.5.5.7.3.2 Client Authentication
Application[1] = 1.3.6.1.5.5.7.3.1 Server Authentication
CertContext[0][1]: dwInfoStatus=102 dwErrorStatus=0
Issuer: CN=SubCA
NotBefore: 13.11.2014 19:12
NotAfter: 13.11.2017 19:22
Subject: CN=EntSubCA, DC=DED, DC=ROOT
Serial: 6109015b000100000008
Template: SubCA
9b 04 17 9f c5 fe 52 ca a5 58 49 6c c6 18 fa db 13 b3 92 9e
Element.dwInfoStatus = CERT_TRUST_HAS_KEY_MATCH_ISSUER (0x2)
Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
---------------- Certificate AIA ----------------
Failed "AIA" Time: 0
Error retrieving URL: The network path was not found. 0x80070035 (WIN32: 53)
file://\\sub_ca\CertEnroll\sub_ca_SubCA(1).crt
Verified "Certificate (0)" Time: 0
[1.0] file://\\ca\crl\SubCA.crt
Verified "Certificate (0)" Time: 4
[2.0] http://webserver/crl/SubCA.crt
---------------- Certificate CDP ----------------
Verified "Base CRL (32)" Time: 0
[0.0] file://\\ca\crl\SubCA.crl
Verified "Base CRL (32)" Time: 4
[1.0] http://webserver/crl/SubCA.crl
---------------- Base CRL CDP ----------------
No URLs "None" Time: 0
---------------- Certificate OCSP ----------------
No URLs "None" Time: 0
CRL 32:
Issuer: CN=SubCA
8d a9 9d 51 65 a3 8e 77 02 22 40 57 62 70 e8 f6 c5 2e 60 1e
CertContext[0][2]: dwInfoStatus=102 dwErrorStatus=0
Issuer: CN=RootCA
NotBefore: 28.05.2008 12:09
NotAfter: 28.05.2058 12:19
Subject: CN=SubCA
Serial: 616bd19f000100000004
Template: SubCA
06 d2 47 e7 dc 8f a7 97 a2 b8 c3 92 03 19 24 0c 47 45 22 14
Element.dwInfoStatus = CERT_TRUST_HAS_KEY_MATCH_ISSUER (0x2)
Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
---------------- Certificate AIA ----------------
Verified "Certificate (0)" Time: 0
[0.0] file://\\ca\crl\RootCA.crt
Verified "Certificate (0)" Time: 4
[1.0] http://webserver/crl/RootCA.crt
---------------- Certificate CDP ----------------
Verified "Base CRL (1c)" Time: 4
[0.0] http://webserver/crl/RootCA.crl
Verified "Base CRL (1c)" Time: 0
[1.0] file://\\ca\crl\RootCA.crl
---------------- Base CRL CDP ----------------
No URLs "None" Time: 0
---------------- Certificate OCSP ----------------
No URLs "None" Time: 0
CRL 1c:
Issuer: CN=RootCA
dc 98 2f 8d 16 9c 64 6e b2 74 89 95 9a 6c 1b 77 fd 58 63 fb
CertContext[0][3]: dwInfoStatus=10c dwErrorStatus=0
Issuer: CN=RootCA
NotBefore: 27.05.2008 16:10
NotAfter: 27.05.2110 16:20
Subject: CN=RootCA
Serial: 258de6fbd3bbab92460530e9e9f10536
5d e4 56 38 13 0a 52 aa 66 51 25 61 19 33 c9 d7 a2 c7 dd 38
Element.dwInfoStatus = CERT_TRUST_HAS_NAME_MATCH_ISSUER (0x4)
Element.dwInfoStatus = CERT_TRUST_IS_SELF_SIGNED (0x8)
Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
---------------- Certificate AIA ----------------
Verified "Certificate (0)" Time: 0
[0.0] file://\\ca\crl\RootCA.crt
Verified "Certificate (0)" Time: 4
[1.0] http://webserver/crl/RootCA.crt
---------------- Certificate CDP ----------------
Verified "Base CRL (1c)" Time: 0
[0.0] file://\\ca\crl\RootCA.crl
Verified "Base CRL (1c)" Time: 4
[1.0] http://webserver/crl/RootCA.crl
---------------- Base CRL CDP ----------------
No URLs "None" Time: 0
---------------- Certificate OCSP ----------------
No URLs "None" Time: 0
CRL 1c:
Issuer: CN=RootCA
dc 98 2f 8d 16 9c 64 6e b2 74 89 95 9a 6c 1b 77 fd 58 63 fb
Issuance[0] = 1.2.700.113556.1.4.7000.233.28688.7.167403.1102261.1593578.2302197.1
Exclude leaf cert:
5b 8d 96 39 f8 a3 6f af f3 89 bc 8d 78 e2 da 53 21 b8 ff aa
Full chain:
ca 99 30 47 9b ad ab ce 97 cc 70 80 a5 4e 11 b3 1a 83 98 78
Verified Issuance Policies: None
Verified Application Policies:
1.3.6.1.5.5.7.3.2 Client Authentication
1.3.6.1.5.5.7.3.1 Server Authentication
ERROR: Verifying leaf certificate revocation status returned The revocation function was unable to check revocation because the revocation server was offline. 0x80092013 (-2146885613)
CertUtil: The revocation function was unable to check revocation because the revocation server was offline.
CertUtil: -verify command completed successfully.

What you have discovered is the reason to *not* use LDAP URLs for CDP and AIA extensions in your PKI. To access those URLs, the account must access to the URLs. In your output, it is quite clear that the local account does not have necessary permissions
(you also use FILE URLs for publication, which again is not recommended).
The best practice is to use a single URL for the CDP extension. It should be an HTTP URL that is hosted on a highly available (internally and externally accessible) Web cluster.
For the AIA extension, it should contain two URLs: one for the CA certificate - again to an internally and externally accessible, highly available Web cluster and one for the OCSP service - also
an internally and externally accessible, highly available Web cluster.
the other issue is that the root CA is *not* trusted when run by a non-domain account. How are you adding the trusted root CA. It is recommended to do this by running
certutil -dspublish -f RootCA.crt.
This will ensure that the computer account trusts the root CA. In your output, the root CA certificate is not trusted.
Brian

Non-domain computer request certificate

Similar Messages

Maybe you are looking for