Authenticated proxy for cert revocation check

Hi guys,
Since upgrading to Java 7u25, Web Start will do a certificate revocation check at startup. Problem is, it seems to be ignoring the proxy authentication settings (I have it set up to user browser settings; tried switching to manual but there's no way to specify a username and password!) and it's locking my account because it tries to access the proxy without credentials. Even stranger, it seems to pass the revocation check eventually... so it seems it's only ignoring it long enough to fire a few failed login attempts. Any ideas how to get around this?

Hi,
Please try the following method.
Certificate revocation checked failed:
http://blogs.technet.com/b/bshukla/archive/2012/04/30/certificate-revocation-checked-failed.aspx
Wendy Liu
TechNet Community Support

Similar Messages

ASA Cut Through (Authentication) Proxy for a Single ACL

I have a customer that wants to authenticate users at the ASA before being allowed access from the outside into a payroll server on the DMZ. I am aware of the cut through proxy feature, but doesn't that affect all traffic entering the DMZ? Is there a way to only authenticate users accessing one server?

Hi,
Seems to me the easiest way to do this is you are connecting to the destination server with either Browser or CLI based connection.
For example if its a browser based connection then you could configure
username password privilege
access-list PROXY-AUTH extended permit tcp any host eq http
access-list PROXY-AUTH extended permit tcp any host eq https
access-list PROXY-AUTH extended deny ip any any
aaa authentication match PROXY-AUTH LAN LOCAL
I don't think you even need the "deny" statement since there is an implicit deny at the end of each ACL
Where "LAN" is my interface "nameif" connect to my LAN network.
To my understanding if you are using some application for this connection that doesnt apply in this situation then you would have to configure this in another way and the user would have to first connect manually to the ASA for authentication and would then be allowed to connect to the resource.
Have a look at this document for some help
http://www.cisco.com/en/US/products/ps6120/products_tech_note09186a0080ba6110.shtml
Hope this helps
- Jouni

IOS 4.3 - Authenticated Proxy + Wireless issues

Okay, I can see a lot of similar titled posts, but none quite have the same issues as we are facing here, so I decided to create a post of my own.
What we have is an 802.1X (AD/RADIUS) wireless network configured (on the iDevices) as a "WPA2 Enterprise" network and using a self-signed certificate. Once configured we also specify an authenticated proxy for the connection. Now, we've supported iDevices here for quite some time without too many issues (aside from the other occassional issue with updated phones, etc). We have everything on our network from "iPhone OS 3.1.2" through iPads with "iOS 4.3" and have been very successful in supporting these devices in the past... until v4.3.
With the new update, we have devices that worked perfectly before (and have been correctly configured) now asking for a username and password when browsing in Safari. We have devices that, on entering the correct information, give us messages such as "Incorrect username or password" or "Unable to join the network <name>". The same devices worked perfectly with iOS 4.2.1 installed. We've tried;
a) Forgetting the networks and setting them up again.
b) Changing the user's password and setting things up again.
c) Resetting network connections and trying again.
d) Resetting the entire phone and trying again.
But to no avail. If you can get wireless configured without either of the above errors messages, it will simply fail to work with the proxy server and cause issues in Safari, etc.
This is emmensly frustrating. We've had to put out a notice to all users to NOT update to v4.3 until this is resolved... which is not cool.
Interestingly, we also had a 3G rock up to the helpdesk today. It had iOS 4.2.1 installed (the latest availaqble for that odel, apparently) and it was exhibiting the same sort of behaviour (and is the only non-4.3 device to do so).
Any thoughts. Do we just need to wait until iOS 4.3.1 to get this fixed (like last time)?

So, I updated a couple of iPads and a few more iPhones yesterday and today. Around 50% success rate - which is weird. Tried the hard-off, reset network, forget network type stuff again, and no joy. Here's an intersting thing though;
a) We can now tap on the SSID and it figures out that it's an enterprise network. Saves chosing the options after tapping the "Other" setting. This also appears to improve the success of accepting the certificate as well. Neat. This didn't used to work.
b) Although the setup looks good, and Exchange just works... we were STILL getting an authentication box in Safari and things were not working correctly. As a test we entered credentials (using email address format - which also appears more successful) and it didn't appear to fix anything, or so we thought. on entering the auth details in Safari, the page that requested it stayed 75% loaded and didn't looks to be working. On closing that window and trying others like "Apple", etc, it appears to work.
I have done this on all the devices that failed and so far so good. So, forget your current network, set up the new enterprise wireless by tapping on the SSID (don't configure using "Other"), enter credentials as email addresses, and authenticate in Safari when you are asked the first time. Reload the page and test.
While this shouldn't make any difference (and is similar to what we tested in v4.3.0), it appears to work for us at the moment.

Telnet Authentication Proxy

Hi,
For telnet ip authentication proxy, is it true that the router only sends username and password to Radius servers? Not the ip source address of the initiated host. So how does source ip of initiated host get added to the downloaded acl from the Radius server? The router adds it?
Thanks.

The Cisco IOS Firewall Authentication Proxy for FTP and/or Telnet Sessions feature in specific versions of Cisco IOS software is vulnerable to a remotely-exploitable buffer overflow condition.
Devices that do not support, or are not configured for Firewall Authentication Proxy for FTP and/or Telnet Services are not affected.
Devices configured with only Authentication Proxy for HTTP and/or HTTPS are not affected.
http://www.cisco.com/en/US/products/products_security_advisory09186a00805117cb.shtml

RDS Gateway 2012, RemoteApp Displays "A Revocation check could not be performed for the Certificate" via RDWEB

I have searched through the forums and there are a number of posts that are similar but all the checks they list seem to not apply to this one.
My current setup is as follows
All Servers are 2012 R2
1 x DC server
1 x RDS Gateway server with RDS Web installed
1 x Session Host Server
Certificate supplied by godaddy with 5 names. (included is the name of the RDS Gateway/Web server in the certificate, the internal name of the session host server is not included as the internal names are differnet to the external)
My tests are as follows
Navigating to the RDSWEB page from a machine inside the same network (windows 7 sp1) but not on the same domain is fine no errors and logging in and launching any published application is fine with no errors.
However logging in on another machine that is external from the network (windows 7 sp1) is ok up to the point of launching any of the published apps I get the error about ""A Revocation check could not be performed for the Certificate". this
prompts twice but does allow you to continue and login and use the app till the next time. If I view the certificate from the warning message all appears to be ok with all certs in the chain.
I have imported the root and intermediate certs to each of the gateway/rdsweb server and session host server into the computer cert store just to be on the safe side. This has not helped, I have also run the following command from both windows 7 machines
with no errors on either
certutil -f –urlfetch -verify c:\export.cer
I cant seem to see where this is failing and I am beginning to think there is something wrong with godaddy cert itself somehow.
If I skip rdsweb and just use MSTSC with the gateway server settings then I can login to any machine on the network with no errors so this is only related to launching published apps on the 2012 R2 RDWEB or session host servers.
Any help appreciated

Hi,
1. Please make sure the client PCs have mstsc.exe (6.3.9600) installed.
2. If you are seeing a name mismatch error, you can set the published name via this cmdlet:
Change published FQDN for Server 2012 or 2012 R2 RDS Deployment
http://gallery.technet.microsoft.com/Change-published-FQDN-for-2a029b80
To be clear, the above cmdlet changes the name that shows up next to Remote computer on the prompt you see when launching a RemoteApp. You should have a DNS A record on your internal network pointing to the private ip address of your RDCB server.
Additionally, in RD Gateway Manager, Properties of your RD RAP, Network Resource tab, you should select Allow users to connect to any network resource or if you choose to use RD Gateway Managed group you will need to add all of the appropriate names to the
group.
For example, when launching a RemoteApp you would see something like Remote computer: rdcb.domain.com and Gateway server: gateway.domain.com . Both of these names need to be on your GoDaddy certificate.
Please verify the above and reply back so that we may assist you further if needed. It is possible you have an issue with the revocation check but I would like you to make sure that the above is in place first.
Thanks.
-TP
Thanks for the response.
To be clear I am only seeing a name mismatch and revocation error if I assign a self signed cert to the session host as advised earlier in the thread by "Dharmesh Solanki", if I remove this and assign the 3rd party certificate I then
just get the revocation error , I have already ran the powershell to change the FQDN's but this has not resolved the issue although the RDP connection details now match the external url for RDWEB when looking at one of the remoteapp files. The workspace
ID still shows an internal name though inside this same file.
RD Gateway is already set to connect any resource, when connecting using remote app both names (RDCB/RDGateway) show as being correct and are contained within the same UCC certificate. I also already have a DNS entry for the Connection broker pointing to
the internal ip.
Do you know if the I need the internal name of the session host servers contained within the same UCC certificate seeing as they are different fqdn's than what I am using for external access ? I resigned the UCC certificate and included the internal name
of the session host server to see if this would help but for some reason I am still seeing the revocation error. I will check on a windows 8 client pc this evening to see if this gets any further as the majority of the testing has been done on windows 7 sp1
client pc's
Thanks

How to use an authenticated user for a proxy call

Dear all,
I am currently working on a JEE application where the user needs to authenticate (for this I have configured the web.xml).
Now inside this application I need to do a proxy call to a PI webservice.
I would like to use the user credentials of the already logged in user in order to call the proxy.
What I don't want to do is to use a service user for the proxy call.
The code I am trying to call looks something like this:
     private IntegratedConfigurationIn getPort() throws Exception{
          IntegratedConfigurationIn port = null;
          try {
               IntegratedConfigurationInService service = null;
               service = new IntegratedConfigurationInService();
               port = (IntegratedConfigurationIn) service.getIntegratedConfigurationIn_Port();
              BindingProvider bp = (BindingProvider)port;
              bp.getRequestContext().put(BindingProvider.USERNAME_PROPERTY, user);
              bp.getRequestContext().put(BindingProvider.PASSWORD_PROPERTY, password);
              if (url.length() != 0)
                   bp.getRequestContext().put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY, url);
          catch (Exception ex){
               ex.printStackTrace();
          return port;
The examples I found to retrieve the userdata pointed to codes similar to this one:
public HttpServletRequest getHttpRequest() throws Exception {
          // Get runtime context
          Properties props = new Properties();
          props.put("domain", "true");
          Context initialContext = new InitialContext(props);
          ApplicationWebServiceContext wsContext = (ApplicationWebServiceContext) initialContext
                    .lookup(" /wsContext/ApplicationWebServiceContext");
          HttpServletRequest req = wsContext.getHttpServletRequest();
          return req;
com.sap.security.api.IUser sapUser = com.sap.security.api.UMFactory.getAuthenticator().getLoggedInUser(getHttpRequest(), null);
          IUser ep5User = com.sapportals.wcm.util.usermanagement.WPUMFactory.getUserFactory().getEP5User(sapUser);
Now I don't know how to bring it togehter and how to use an authenticated user for the BindingProvider.
I would appreciate any hints or ideas.

Peter,
from the first screenshot, what I understood is that, you are calling an inbound PI web service that is intended to create an integrated configuration object (this is used for whole lot of other reason completely) but not actually calling a development web service.
For this, you would have to generate your client classes from the WSDL provided by the PI developer for that particular service. Once you get those client classes generated, you could used the method provided in the other screenshot to extract the user and password and call the intended web service.
Vijay Konam

Cut-Through Proxy / Authentication Proxy on Cisco ASA using ISE as AAA Server for allocating SGTs

Hi,
We are trying to setup ASA to do cut-through authentication proxy, and use ISE as RADIUS. We can successfully authenticate the user from Radius on the ASA, while he opens a web-page, but then it displays the error: authorization denied.
What we want:
ISE to allocate a security group tag to the user session when he logs in, that tag would carried within out cisco network infrastrucutre to define the access
policy for that user.
Can someone please help me with a sort of step by step thing for ISE configuration to allocate SGTs/SGACL for the user session after authentication is completed.
Thanks
Lovleen

Please refer to below step by step config guide for security group access policies
http://www.cisco.com/c/en/us/td/docs/security/ise/1-2/user_guide/ise_user_guide/ise_sga_pol.html

How to disable checks for certificate revocation on Java 7 u25

I have updated a standalone network to Java 7 update 25. With this new version is an option to "Perform certificate revocation checks on". Since this checks against sources published to the outside network, it fails to allow users on the standalone network to use some Java applications. This is remedied by checking Do not check. However, I need to be able to push this setting out to all users on the network.
Does anyone have or know a way to make this change through the registry or a config file?

For Internal webauth - HTTP & HTTPs redirection is possible on 7.0 & 7.2 code on WLC. See the difference below.
On 7.0 code both webauth redirection & wlc management were global, Disabling http management disables http webauth redirection, same for https as well. This behavior is changed in 7.2.
On 7.2 code, You can have both HTTP & HTTPs management enabled and configure either HTTP or HTTPs redirection. use the below command to control http or https redirection.
(Cisco Controller) >config network web-auth secureweb enable/disable
Enable - Enables https for web-auth redirection.
Disable - Enables http for web-auth redirection.

How to set expiry time for cached Subjects of authenticated proxy service.

How to set expiry time for cached Subjects of authenticated proxy service in message level authentication.
Because of this, password change does not effect immediatly in proxy invocation.
I'm using Weblogic 10.3 and OSB3.0

Hi,
You can activate Time-Dependent Publishing Service on your XML form and once the Lifetime of Documents is over then the document is not visible to users.
http://help.sap.com/saphelp_nw2004s/helpdata/en/c1/c87d3cf8ff3934e10000000a11405a/frameset.htm
It is only invisible but not deleted!
So to delete all expired XML Forms you should run Scheduler Tasks for Time-Dependent Publishing:
<b>TimeBasePublishingUnpublish</b>
http://help.sap.com/saphelp_nw2004s/helpdata/en/3a/bc37b5789dee4eaa8005bff84f14cf/frameset.htm
You can also create your own Scheduler Task which deletes/archieves all expired XML Forms.
Greetings,
Praveen Gudapati
[Points are welcome for helpful answers]

Defining an Authentication Scheme for user ID and password and client certi

Hi,
                I do need to define an Authentication Scheme for user ID/Password and client certificate,, both at the same time, so whenever the end user access the SAP Portal he/she will be asked to provide user and password as well digital certificate,
                Despite of the whole idea behind o f the concept of digital certificate, my client sill wants to keep the user ID and password to complies with business requirements.
     I found a documentation that discuss Authentication Scheme with example using both ID and Digital certificate, but the priority was set different for each authentication method.
http://help.sap.com/saphelp_nw04s/helpdata/en/d3/1dd4516c518645a59e5cff2628a5c1/content.htm
     So I am wondering with I can accomplish User ID/Pwd plus digital certificate just by making the priority the same value. Anyone had a similar requirement?
Best Regards
Claudio Rocha

Hi
Did you get an answer for this Query ?
Regards
Priyanka

EMC - Certificate status could not be determined because revocation check failed.

I've exhausted my resources on this issue and am reaching out for some assistance. I have setup Server 2008 R2 Enterprise SP1, running Exchange 2010 SP1. In EMC I have successfully imported a GoDaddy SSL certificate. Although I am receiving the message -
"The certificate status could not be determined because the revocation check failed."
Here are the steps I've taken to troubleshoot this so far:
[PS] C:\Users\Administrator\Desktop>netsh winhttp show proxy
Current WinHTTP proxy settings:
Direct access (no proxy server).
As you can see, direct access. Which is true, no proxy's on this network.
For good measure, I'll dump the urlcache.
certutil -urlcache ocsp delete
certutil -urlcache crl delete
Both return 0, reboot server.
Comes back up, same message in EMC.
From PS, I test exactly what its getting from GoDaddy.
[PS] C:\Users\Administrator\Desktop>certutil -f -urlfetch -verify mail.fluxlabs.net.crt
Issuer:
SERIALNUMBER=07969287
CN=Go Daddy Secure Certification Authority
OU=http://certificates.godaddy.com/repository
O=GoDaddy.com, Inc.
L=Scottsdale
S=Arizona
C=US
Subject:
CN=mail.fluxlabs.net
OU=Domain Control Validated
O=mail.fluxlabs.net
Cert Serial Number: 27b60918638e0d
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)
SimpleChain.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
SimpleChain.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN (0x40)
SimpleChain.dwErrorStatus = CERT_TRUST_IS_OFFLINE_REVOCATION (0x1000000)
CertContext[0][0]: dwInfoStatus=102 dwErrorStatus=1000040
Issuer: SERIALNUMBER=07969287, CN=Go Daddy Secure Certification Authority, OU=http://certificates.godaddy.com/repository, O="GoDaddy.com, Inc.", L=S
cottsdale, S=Arizona, C=US
NotBefore: 8/20/2011 7:49 PM
NotAfter: 8/20/2012 7:16 PM
Subject: CN=mail.fluxlabs.net, OU=Domain Control Validated, O=mail.fluxlabs.net
Serial: 27b60918638e0d
SubjectAltName: DNS Name=mail.fluxlabs.net, DNS Name=www.mail.fluxlabs.net
33 49 57 5d 6e d8 6b aa b9 61 73 95 44 07 c9 2e 55 6e 47 10
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 ----------------
Verified "Certificate (0)" Time: 4
[0.0] http://certificates.godaddy.com/repository/gd_intermediate.crt
---------------- Certificate CDP ----------------
Expired "Base CRL (05)" Time: 4
[0.0] http://crl.godaddy.com/gds1-55.crl
---------------- Base CRL CDP ----------------
No URLs "None" Time: 0
---------------- Certificate OCSP ----------------
Expired "OCSP" Time: 4
[0.0] http://ocsp.godaddy.com/
CRL (null):
Issuer: CN=Go Daddy Validation Authority, OU=http://certs.godaddy.com/repository/, O="GoDaddy.com, Inc.", L=Scottsdale, S=Arizona, C=US
e5 53 19 6c 54 87 8c 62 23 1b b9 11 e1 d8 3d 3f b2 04 77 3f
Issuance[0] = 2.16.840.1.114413.1.7.23.1
Application[0] = 1.3.6.1.5.5.7.3.1 Server Authentication
Application[1] = 1.3.6.1.5.5.7.3.2 Client Authentication
CertContext[0][1]: dwInfoStatus=102 dwErrorStatus=0
Issuer: OU=Go Daddy Class 2 Certification Authority, O="The Go Daddy Group, Inc.", C=US
NotBefore: 11/15/2006 8:54 PM
NotAfter: 11/15/2026 8:54 PM
Subject: SERIALNUMBER=07969287, CN=Go Daddy Secure Certification Authority, OU=http://certificates.godaddy.com/repository, O="GoDaddy.com, Inc.", L=
Scottsdale, S=Arizona, C=US
Serial: 0301
7c 46 56 c3 06 1f 7f 4c 0d 67 b3 19 a8 55 f6 0e bc 11 fc 44
Element.dwInfoStatus = CERT_TRUST_HAS_KEY_MATCH_ISSUER (0x2)
Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
---------------- Certificate AIA ----------------
No URLs "None" Time: 0
---------------- Certificate CDP ----------------
Verified "Base CRL" Time: 4
[0.0] http://certificates.godaddy.com/repository/gdroot.crl
---------------- Base CRL CDP ----------------
No URLs "None" Time: 0
---------------- Certificate OCSP ----------------
Expired "OCSP" Time: 4
[0.0] http://ocsp.godaddy.com
CRL (null):
Issuer: OU=Go Daddy Class 2 Certification Authority, O="The Go Daddy Group, Inc.", C=US
da 1e d5 63 5c 05 58 50 4e db d2 4e e8 9d 28 9d c4 36 b3 1e
Application[0] = 1.3.6.1.5.5.7.3.1 Server Authentication
Application[1] = 1.3.6.1.5.5.7.3.2 Client Authentication
Application[2] = 1.3.6.1.5.5.7.3.4 Secure Email
Application[3] = 1.3.6.1.5.5.7.3.3 Code Signing
CertContext[0][2]: dwInfoStatus=109 dwErrorStatus=0
Issuer: OU=Go Daddy Class 2 Certification Authority, O="The Go Daddy Group, Inc.", C=US
NotBefore: 6/29/2004 12:06 PM
NotAfter: 6/29/2034 12:06 PM
Subject: OU=Go Daddy Class 2 Certification Authority, O="The Go Daddy Group, Inc.", C=US
Serial: 00
27 96 ba e6 3f 18 01 e2 77 26 1b a0 d7 77 70 02 8f 20 ee e4
Element.dwInfoStatus = CERT_TRUST_HAS_EXACT_MATCH_ISSUER (0x1)
Element.dwInfoStatus = CERT_TRUST_IS_SELF_SIGNED (0x8)
Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
---------------- Certificate AIA ----------------
No URLs "None" Time: 0
---------------- Certificate CDP ----------------
No URLs "None" Time: 0
---------------- Certificate OCSP ----------------
No URLs "None" Time: 0
Application[0] = 1.3.6.1.5.5.7.3.1 Server Authentication
Application[1] = 1.3.6.1.5.5.7.3.2 Client Authentication
Application[2] = 1.3.6.1.5.5.7.3.4 Secure Email
Application[3] = 1.3.6.1.5.5.7.3.3 Code Signing
Exclude leaf cert:
b1 04 4b 90 a1 d3 48 de 46 bd d7 50 20 e3 44 b8 3f 68 39 f7
Full chain:
68 36 4d 37 2e 96 bd d2 aa 77 3f d0 e8 78 a9 e6 68 bd 7d 71
Verified Issuance Policies:
2.16.840.1.114413.1.7.23.1
Verified Application Policies:
1.3.6.1.5.5.7.3.1 Server Authentication
1.3.6.1.5.5.7.3.2 Client Authentication
Cert is an End Entity certificate
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.
As you can see, the "revocation server is offline."
So I run the same test from another server on the LAN.
Verified Issuance Policies:
2.16.840.1.114413.1.7.23.1
Verified Application Policies:
1.3.6.1.5.5.7.3.1 Server Authentication
1.3.6.1.5.5.7.3.2 Client Authentication
Cert is an End Entity certificate
Leaf certificate revocation check passed
CertUtil: -verify command completed successfully.
It passes. The server's firewall has been disabled. DNS cache has been cleared. I have verified everything I can, and still failing to verify.

[PS] C:\Users\Administrator\Desktop>Get-ExchangeCertificate |fl
AccessRules : {System.Security.AccessControl.CryptoKeyAccessRule, System.Security.AccessControl.CryptoKeyAccessRule, System.Security.Acces
trol.CryptoKeyAccessRule}
CertificateDomains : {mail.fluxlabs.net, www.mail.fluxlabs.net}
HasPrivateKey : True
IsSelfSigned : False
Issuer : SERIALNUMBER=07969287, CN=Go Daddy Secure Certification Authority, OU=http://certificates.godaddy.com/repository, O="GoDaddy
, Inc.", L=Scottsdale, S=Arizona, C=US
NotAfter : 8/20/2012 7:16:57 PM
NotBefore : 8/20/2011 7:49:30 PM
PublicKeySize : 2048
RootCAType : ThirdParty
SerialNumber : 27B60918638E0D
Services : IMAP, POP, IIS, SMTP
Status : RevocationCheckFailure
Subject : CN=mail.fluxlabs.net, OU=Domain Control Validated, O=mail.fluxlabs.net
Thumbprint : 3349575D6ED86BAAB96173954407C92E556E4710
[PS] C:\Users\Administrator\Desktop>Enable-ExchangeCertificate -Thumbprint 3349575D6ED86BAAB96173954407C92E556E4710 -Services POP,IMAP,SMTP,IIS
The command has already been executed. Yes, I have seen those sites. Neither have worked. Like I said, it is directly connected; and no proxies are set.
-- Jeremy MCSpadden Flux Labs

Java Webstart application problem with TLS certificate revocation checks (Java 1.7.0_76)

We have a problem with our Java Web Start Application regarding the TLS certificate revocation check:
The application is running on a server within a wide area network which is separated from the internet.
The application users have access to the WAN, and also access to the internet over some corporate proxy/firewall.
The user has to enter, for example "https://my-site.de/myapp/ma.jnlp" within a webbrowser or could also call "javaws https://my-site.de/myapp/ma.jnlp" to start the application client.
The webserver has a certificate from a trusted certificate authority. This certificate seems to be ok, the browser is even configured to perform OCSP status check.
The application files are signed with a certificate from another trusted certificate authority. This certificate seems also to be ok. Regarding this certificate there
are no problems with certificate revocation checks.
The problem is, while starting the application client there is a message box which tell us something like "the connection to this website ist not trustworthy",
"Website: https://my-site.de:80", and something about an invalid certificate, meaning the webserver certificate.
Obviously the jvm runtime, which is executed on the users workstation, tries to perform a revocation check for the webservers certificate, but this fails because
it cannot fetch the certificate under https://my-site.de:80.
The application will execute without further problems after that message but the users are very concerned about the "invalid" certificate, so here are my questions:
- Why is the application trying to get the webserver certificate over Port 80. Our application developers told me, there is no corresponding statement. Calling this address
has to fail while "https://my-site.de:443" or "https://my-site.de" would not have a problem.
- Is there a way to make the application go on without performing a tls revocation check? I mean, by adjusting the application sourcecode and not by configuring the users Java Control Panel.
While disabling the TLS Certificate Revocation check in the Java Control Panel, the Webstart Application executes without a warning message, but this is not a workable solution for
our users.
It would be great if someone can help me with a hint so i can send our developers into the right direction;-)
Many thanks!
This is a part from a java console output after calling "javaws -verbose https://my-site.de/myapp/"
(sorry for this is in german... and also my english above)
network: Verbindung von http://ocsp.serverpass.telesec.de/ocspr mit Proxy=HTTP @ internet-proxy.***:80 wird hergestellt
network: Verbindung von http://ocsp.serverpass.telesec.de/ocspr mit Proxy=HTTP @ internet-proxy.***:80 wird hergestellt
security: OCSP Response: GOOD
network: Verbindung von http://ocsp.serverpass.telesec.de/ocspr mit Proxy=HTTP @ internet-proxy.***:80 wird hergestellt
security: UNAUTHORIZED
security: Failing over to CRLs: java.security.cert.CertPathValidatorException: OCSP response error: UNAUTHORIZED
network: Cacheeintrag gefunden [URL: http://crl.serverpass.telesec.de/rl/TeleSec_ServerPass_CA_1.crl, Version: null] prevalidated=false/0
cache: Adding MemoryCache entry: http://crl.serverpass.telesec.de/rl/TeleSec_ServerPass_CA_1.crl
cache: Resource http://crl.serverpass.telesec.de/rl/TeleSec_ServerPass_CA_1.crl has expired.
network: Verbindung von http://crl.serverpass.telesec.de/rl/TeleSec_ServerPass_CA_1.crl mit Proxy=HTTP @ internet-proxy.***:80 wird hergestellt
network: Verbindung von http://crl.serverpass.telesec.de/rl/TeleSec_ServerPass_CA_1.crl mit Proxy=HTTP @ internet-proxy.***:80 wird hergestellt
network: ResponseCode für http://crl.serverpass.telesec.de/rl/TeleSec_ServerPass_CA_1.crl: 200
network: Codierung für http://crl.serverpass.telesec.de/rl/TeleSec_ServerPass_CA_1.crl: null
network: Verbindung mit http://crl.serverpass.telesec.de/rl/TeleSec_ServerPass_CA_1.crl trennen
CacheEntry[http://crl.serverpass.telesec.de/rl/TeleSec_ServerPass_CA_1.crl]: updateAvailable=true,lastModified=Tue Mar 24 10:50:01 CET 2015,length=53241
network: Verbindung von http://crl.serverpass.telesec.de/rl/TeleSec_ServerPass_CA_1.crl mit Proxy=HTTP @ internet-proxy.***:80 wird
network: Verbindung von socket://ldap.serverpass.telesec.de:389 mit Proxy=DIRECT wird hergestellt
security: Revocation Status Unknown
com.sun.deploy.security.RevocationChecker$StatusUnknownException: java.security.cert.CertPathValidatorException: OCSP response error: UNAUTHORIZED
    at com.sun.deploy.security.RevocationChecker.checkOCSP(Unknown Source)
    at com.sun.deploy.security.RevocationChecker.check(Unknown Source)
    at com.sun.deploy.security.RevocationCheckHelper.doRevocationCheck(Unknown Source)
    at com.sun.deploy.security.RevocationCheckHelper.doRevocationCheck(Unknown Source)
    at com.sun.deploy.security.RevocationCheckHelper.checkRevocationStatus(Unknown Source)
    at com.sun.deploy.security.X509TrustManagerDelegate.checkTrusted(Unknown Source)
    at com.sun.deploy.security.X509Extended7DeployTrustManagerDelegate.checkServerTrusted(Unknown Source)
    at com.sun.deploy.security.X509Extended7DeployTrustManager.checkServerTrusted(Unknown Source)
    at sun.security.ssl.ClientHandshaker.serverCertificate(Unknown Source)
    at sun.security.ssl.ClientHandshaker.processMessage(Unknown Source)
    at sun.security.ssl.Handshaker.processLoop(Unknown Source)
    at sun.security.ssl.Handshaker.process_record(Unknown Source)
    at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source)
    at sun.security.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source)
    at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
    at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
    at sun.net.www.protocol.https.HttpsClient.afterConnect(Unknown Source)
    at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(Unknown Source)
    at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
    at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(Unknown Source)
    at com.sun.deploy.net.HttpUtils.followRedirects(Unknown Source)
    at com.sun.deploy.net.BasicHttpRequest.doRequest(Unknown Source)
    at com.sun.deploy.net.BasicHttpRequest.doGetRequestEX(Unknown Source)
    at com.sun.deploy.cache.ResourceProviderImpl.checkUpdateAvailable(Unknown Source)
    at com.sun.deploy.cache.ResourceProviderImpl.isUpdateAvailable(Unknown Source)
    at com.sun.deploy.cache.ResourceProviderImpl.getResource(Unknown Source)
    at com.sun.deploy.cache.ResourceProviderImpl.getResource(Unknown Source)
    at com.sun.deploy.model.ResourceProvider.getResource(Unknown Source)
    at com.sun.javaws.jnl.LaunchDescFactory._buildDescriptor(Unknown Source)
    at com.sun.javaws.jnl.LaunchDescFactory.buildDescriptor(Unknown Source)
    at com.sun.javaws.jnl.LaunchDescFactory.buildDescriptor(Unknown Source)
    at com.sun.javaws.Main.launchApp(Unknown Source)
    at com.sun.javaws.Main.continueInSecureThread(Unknown Source)
    at com.sun.javaws.Main.access$000(Unknown Source)
    at com.sun.javaws.Main$1.run(Unknown Source)
    at java.lang.Thread.run(Unknown Source)
    Suppressed: com.sun.deploy.security.RevocationChecker$StatusUnknownException
        at com.sun.deploy.security.RevocationChecker.checkCRLs(Unknown Source)
        ... 35 more
Caused by: java.security.cert.CertPathValidatorException: OCSP response error: UNAUTHORIZED
    at sun.security.provider.certpath.OCSP.check(Unknown Source)
    at sun.security.provider.certpath.OCSP.check(Unknown Source)
    at sun.security.provider.certpath.OCSP.check(Unknown Source)
    ... 36 more
security: Ungültiges Zertifikat vom HTTPS-Server
network: Cacheeintrag nicht gefunden [URL: https://my-site.de:80, Version: null]

Add the JSF Jars to the WEB-INF/lib directory of the application. If still getting error add to the CLASSPATH variable in the startWebLogic script in the domain/bin directory.

Exchange 2010 - The certificate status could not be determined because the revocation check failed.

I have tried everything I have found online to get my DigiCert to work.
I have exported the cert and imported it into my child domains and they look perfect.
It is just my parent domain having issues.
netsh winhttp show proxy
does show my correct proxy server for http and https and port 8080
I have tried name, FQDN and IP address.
In the Bypass-list I have tried none, *.domain.com, and a list of all domains and child domains in my forest.
I have flushed the cache
certutil -urlcache crl delete
certutil -urlcache ocsp delete
and rebooted the Exchange 2010 (Windows 2008 R2) server
No matter what, I still see in my Server Configuration for the parent domain's DigiCert cert the message
The certificate status could not be determined because the revocation check failed.
with a red X on the left hand icon. Again, Child domains all say "The certificate is valid for Exchange Server usage."
Note: In spite of having the red X, I was able to assign via EMS the services.
Webmail works fine. Outlook Anywhere fails... I suspect it is due to my red X problem.
Suggestions?
Thanks in Advance
Jim.
Jim.

I have contacted DigiCert and they said the cert is working per their utility, hence the problem is outside the scope of their support.
I have followed, several times, http://support.microsoft.com/kb/979694
http://www.digicert.com/help/ reports all is well.
The DigiCertUtil.exe reports all is well and happy.
I have run
netsh winhttp set proxy proxy-server="http=myproxy:8080;https=myproxy:8080" bypass-list="*.mydomain.com"
Current WinHTTP proxy settings:
Proxy Server(s) : http=myproxy:8080;https=myproxy:8080
Bypass List : *.mydomain.com
I have flushed the cache using the commands
certutil -urlcache crl delete
certutil -urlcache ocsp delete
I still see in my Server Configuration for the parent domain's DigiCert cert the message
"The certificate status could not be determined because the revocation check failed."
with a red X on the left hand certificate icon.
To verify the cert via command line:
certutil -verify -urlfetch c:\mail_domain_com.cer
LoadCert(Cert) returned ASN1 bad tag value met. 0x8009310b (ASN: 267)
CertUtil: -verify command FAILED: 0x8009310b (ASN: 267)
CertUtil: ASN1 bad tag value met.
I suspect this is why I cannot get Outlook Anywhere to connect.
Child domains show a happy certificate icon. Parent domain does not.
Still scratching my head.
Thanks all!
Jim.

Exchange Certificate - Revocation Check Failed

Hi,
the scenario is the following:
Windows 2012 R2 domain
Exchange 2010
Windows 2012 R2 PKI (1 CA Root stand alone. 1 CA Subordinate Enterprise)
At Exchange, I get the following error:
The certificate details are:
I guess that revocation check error is due to "%20" at ldap path (second image).
The questions are:
The "%20" is a normal behavior at "CRL Distribution Points" details in the certificate?
if no
How to delete "%20" in the certificate?
Thanks in advance!

Thanks Mark.
The output from issuing CA:
Issuer:
    CN=SERVSUBUCA
    DC=servicioscorp
    DC=pbo
Name Hash(sha1): 3f202eaecb344a1d5f7cefa0ef305ccc4f11764b
Name Hash(md5): d096ae4af2bbf1f9b7246c5c51f979cb
Subject:
    CN=uiomatrv-exca01.servicioscorp.pbo
    OU=IT
    O=PRODUBANCO
    L=Quito
    S=Pichincha
    C=EC
Name Hash(sha1): dbed6b31170d7ea3c36e08e4b7012a4595108527
Name Hash(md5): bd573e0501d5e3d3a8cdcd229dd40a2e
Cert Serial Number: 620000001168945925b163ff5d000000000011
dwFlags = CA_VERIFY_FLAGS_CONSOLE_TRACE (0x20000000)
dwFlags = CA_VERIFY_FLAGS_DUMP_CHAIN (0x40000000)
ChainFlags = CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT (0x40000000)
HCCE_LOCAL_MACHINE
CERT_CHAIN_POLICY_BASE
-------- CERT_CHAIN_CONTEXT --------
ChainContext.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
ChainContext.dwRevocationFreshnessTime: 32 Days, 5 Minutes, 4 Seconds
SimpleChain.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
SimpleChain.dwRevocationFreshnessTime: 32 Days, 5 Minutes, 4 Seconds
CertContext[0][0]: dwInfoStatus=102 dwErrorStatus=0
Issuer: CN=SERVSUBUCA, DC=servicioscorp, DC=pbo
NotBefore: 8/4/2014 11:10 AM
NotAfter: 8/3/2016 11:10 AM
Subject: CN=uiomatrv-exca01.servicioscorp.pbo, OU=IT, O=PRODUBANCO, L=Quito, S=Pichincha, C=EC
Serial: 620000001168945925b163ff5d000000000011
SubjectAltName: DNS Name=uiomatrv-exca01.servicioscorp.pbo, DNS Name=gyesitev-exca01.servicioscorp.pbo, DNS Name=gyesitev-exca01, DNS Name=uiomatrv-exca01
Template: WebServer
0e180ca4a6642be3709465fd1db4d9a6fa3be717
Element.dwInfoStatus = CERT_TRUST_HAS_KEY_MATCH_ISSUER (0x2)
Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
---------------- Certificate AIA ----------------
No CRL "Certificate (0)" Time: 0
    [0.0] ldap:///CN=SERVSUBUCA,CN=AIA,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=servicioscorp,DC=pbo?cACertificate?base?objectClass=certificationAuthority
---------------- Certificate CDP ----------------
Verified "Base CRL (2b)" Time: 0
    [0.0] ldap:///CN=SERVSUBUCA,CN=UIOMATRV-CERT02,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=servicioscorp,DC=pbo?certificateRevocationList?base?objectClass=cRLDistributionPoint
Verified "Delta CRL (2b)" Time: 0
    [0.0.0] ldap:///CN=SERVSUBUCA,CN=UIOMATRV-CERT02,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=servicioscorp,DC=pbo?deltaRevocationList?base?objectClass=cRLDistributionPoint
---------------- Base CRL CDP ----------------
OK "Delta CRL (2f)" Time: 0
    [0.0] ldap:///CN=SERVSUBUCA,CN=UIOMATRV-CERT02,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=servicioscorp,DC=pbo?deltaRevocationList?base?objectClass=cRLDistributionPoint
---------------- Certificate OCSP ----------------
No URLs "None" Time: 0
    CRL 2b:
    Issuer: CN=SERVSUBUCA, DC=servicioscorp, DC=pbo
    ThisUpdate: 7/30/2014 2:31 PM
    NextUpdate: 8/14/2014 2:51 AM
    507e17f28e96054ead075e0cf353ea1cefbc4d9f
    Delta CRL 2f:
    Issuer: CN=SERVSUBUCA, DC=servicioscorp, DC=pbo
    ThisUpdate: 8/3/2014 2:32 PM
    NextUpdate: 8/5/2014 2:52 AM
    52827a7c7b5f621e2db4aa6b76f9fc448a35e50b
Application[0] = 1.3.6.1.5.5.7.3.1 Server Authentication
CertContext[0][1]: dwInfoStatus=102 dwErrorStatus=0
Issuer: CN=SERVROOTCA
NotBefore: 6/18/2014 1:53 PM
NotAfter: 6/18/2024 2:03 PM
Subject: CN=SERVSUBUCA, DC=servicioscorp, DC=pbo
Serial: 2d000000024a75bdddb4ea0374000000000002
Template: SubCA
5b61be4e5ef53895a1475a89a986302a26cc34a8
Element.dwInfoStatus = CERT_TRUST_HAS_KEY_MATCH_ISSUER (0x2)
Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
---------------- Certificate AIA ----------------
No URLs "None" Time: 0
---------------- Certificate CDP ----------------
No URLs "None" Time: 0
---------------- Base CRL CDP ----------------
No URLs "None" Time: 0
---------------- Certificate OCSP ----------------
No URLs "None" Time: 0
    CRL 03:
    Issuer: CN=SERVROOTCA
    ThisUpdate: 7/3/2014 11:59 AM
    NextUpdate: 7/4/2015 12:19 AM
    34931efb937f7495ce869f635823bbd9e3df578a
CertContext[0][2]: dwInfoStatus=10c dwErrorStatus=0
Issuer: CN=SERVROOTCA
NotBefore: 6/18/2014 1:08 PM
NotAfter: 6/18/2029 1:18 PM
Subject: CN=SERVROOTCA
Serial: 63f24946f2448c9242ce44936f1f759e
1cd3339f1c7717ff77921ca53408a9d7ca58a5f7
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 ----------------
No URLs "None" Time: 0
---------------- Certificate CDP ----------------
  No URLs "None" Time: 0
---------------- Certificate OCSP ----------------
No URLs "None" Time: 0
Exclude leaf cert:
e594318b0d857c2fcb9d08db80637e278ad891df
Full chain:
a0215d71e05618f20649331ea9541930154344eb
Verified Issuance Policies: None
Verified Application Policies:
    1.3.6.1.5.5.7.3.1 Server Authentication
Leaf certificate revocation check passed
CertUtil: -verify command completed successfully.
The output from Exchange:
Issuer:
    CN=SERVSUBUCA
    DC=servicioscorp
    DC=pbo
Subject:
    CN=uiomatrv-exca01.servicioscorp.pbo
    OU=IT
    O=PRODUBANCO
    L=Quito
    S=Pichincha
    C=EC
Cert Serial Number: 620000001168945925b163ff5d000000000011
dwFlags = CA_VERIFY_FLAGS_CONSOLE_TRACE (0x20000000)
dwFlags = CA_VERIFY_FLAGS_DUMP_CHAIN (0x40000000)
ChainFlags = CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT (0x40000000)
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.dwRevocationFreshnessTime: 21 Hours, 31 Minutes, 44 Seconds
SimpleChain.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
SimpleChain.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN (0x40)
SimpleChain.dwRevocationFreshnessTime: 21 Hours, 31 Minutes, 44 Seconds
CertContext[0][0]: dwInfoStatus=102 dwErrorStatus=0
Issuer: CN=SERVSUBUCA, DC=servicioscorp, DC=pbo
NotBefore: 04/08/2014 11:10
NotAfter: 03/08/2016 11:10
Subject: CN=uiomatrv-exca01.servicioscorp.pbo, OU=IT, O=PRODUBANCO, L=Quito, S=Pichincha, C=EC
Serial: 620000001168945925b163ff5d000000000011
SubjectAltName: DNS Name=uiomatrv-exca01.servicioscorp.pbo, DNS Name=gyesitev-exca01.servicioscorp.pbo, DNS Name=gyesitev-exca01, DNS Name=uiomatrv-exca01
Template: WebServer
17 e7 3b fa a6 d9 b4 1d fd 65 94 70 e3 2b 64 a6 a4 0c 18 0e
Element.dwInfoStatus = CERT_TRUST_HAS_KEY_MATCH_ISSUER (0x2)
Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
---------------- Certificate AIA ----------------
No CRL "Certificate (0)" Time: 0
    [0.0] ldap:///CN=SERVSUBUCA,CN=AIA,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=servicioscorp,DC=pbo?cACertificate?base?objectClass=certificationAuthority
---------------- Certificate CDP ----------------
Verified "Base CRL (2b)" Time: 0
    [0.0] ldap:///CN=SERVSUBUCA,CN=UIOMATRV-CERT02,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=servicioscorp,DC=pbo?certificateRevocationList?base?objectClass=cRLDistributionPoint
Verified "Delta CRL (2b)" Time: 0
    [0.0.0] ldap:///CN=SERVSUBUCA,CN=UIOMATRV-CERT02,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=servicioscorp,DC=pbo?deltaRevocationList?base?objectClass=cRLDistributionPoint
---------------- Base CRL CDP ----------------
OK "Delta CRL (2f)" Time: 0
    [0.0] ldap:///CN=SERVSUBUCA,CN=UIOMATRV-CERT02,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=servicioscorp,DC=pbo?deltaRevocationList?base?objectClass=cRLDistributionPoint
---------------- Certificate OCSP ----------------
No URLs "None" Time: 0
    CRL 2b:
    Issuer: CN=SERVSUBUCA, DC=servicioscorp, DC=pbo
    9f 4d bc ef 1c ea 53 f3 0c 5e 07 ad 4e 05 96 8e f2 17 7e 50
    Delta CRL 2f:
    Issuer: CN=SERVSUBUCA, DC=servicioscorp, DC=pbo
    0b e5 35 8a 44 fc f9 76 6b aa b4 2d 1e 62 5f 7b 7c 7a 82 52
Application[0] = 1.3.6.1.5.5.7.3.1 Server Authentication
CertContext[0][1]: dwInfoStatus=102 dwErrorStatus=40
Issuer: CN=SERVROOTCA
NotBefore: 18/06/2014 13:53
NotAfter: 18/06/2024 14:03
Subject: CN=SERVSUBUCA, DC=servicioscorp, DC=pbo
Serial: 2d000000024a75bdddb4ea0374000000000002
Template: SubCA
a8 34 cc 26 2a 30 86 a9 89 5a 47 a1 95 38 f5 5e 4e be 61 5b
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)
---------------- Certificate AIA ----------------
No URLs "None" Time: 0
---------------- Certificate CDP ----------------
No URLs "None" Time: 0
---------------- Certificate OCSP ----------------
No URLs "None" Time: 0
CertContext[0][2]: dwInfoStatus=10c dwErrorStatus=0
Issuer: CN=SERVROOTCA
NotBefore: 18/06/2014 13:08
NotAfter: 18/06/2029 13:18
Subject: CN=SERVROOTCA
Serial: 63f24946f2448c9242ce44936f1f759e
f7 a5 58 ca d7 a9 08 34 a5 1c 92 77 ff 17 77 1c 9f 33 d3 1c
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 ----------------
No URLs "None" Time: 0
---------------- Certificate CDP ----------------
No URLs "None" Time: 0
---------------- Certificate OCSP ----------------
No URLs "None" Time: 0
Exclude leaf cert:
24 b9 1e b2 79 76 b0 16 2d 6d ae e2 cd 6b 98 aa 5f 27 38 20
Full chain:
7b 8c 64 0e 02 42 5a 7e 2d 1a 8b d4 db 3a c2 9c 10 a9 13 56
Issuer: CN=SERVSUBUCA, DC=servicioscorp, DC=pbo
NotBefore: 04/08/2014 11:10
NotAfter: 03/08/2016 11:10
Subject: CN=uiomatrv-exca01.servicioscorp.pbo, OU=IT, O=PRODUBANCO, L=Quito, S=Pichincha, C=EC
Serial: 620000001168945925b163ff5d000000000011
SubjectAltName: DNS Name=uiomatrv-exca01.servicioscorp.pbo, DNS Name=gyesitev-exca01.servicioscorp.pbo, DNS Name=gyesitev-exca01, DNS Name=uiomatrv-exca01
Template: WebServer
17 e7 3b fa a6 d9 b4 1d fd 65 94 70 e3 2b 64 a6 a4 0c 18 0e
The revocation function was unable to check revocation for the certificate. 0x80092012 (-2146885614)
Revocation check skipped -- no revocation information available
Leaf certificate revocation check passed
CertUtil: -verify command completed successfully.
Thanks in advance!

Revocation checked failed status in Certificate on Exchange 2013

Hi,
Got error in certificate that we have get from Godaddy for exchange 2013 which was earlier working fine, but now getting error on status that Revocation checked failed and because of that in outlook user getting certificate error.
please suggest to fix this issue.

We've had this error before, and it was solved by configuring the proxy settings.
> via netsh winhttp set proxy
> set-exchangeserver InternetWebProxy setting (don't know if still
applicable in Exchange2013)
> iexplorer proxy settings
ps : You can also
check the crl location, when you take a look into the properties of the certificate. (crl distribution points)

Authenticated proxy for cert revocation check

Similar Messages

Maybe you are looking for