Replies: 17 comments
-
You're seeing the message "Your signature was not authorized by the OCSP Server" because the OCSP response returned as "UNAUTHORIZED." Please verify certificate. |
Beta Was this translation helpful? Give feedback.
-
I understand. I have talked to AP we’re trying to communicate with, they tell me that the ocsp url is an amazon ocsp-server. They use certificate from Amazon, we use Digicert. I’m not sure what certificate I need to verify, how, and why all the other AP works fine.. We are planing to remove our AP thats why the upgrade have not happend. Maybe we have to just upgrade and delay the removal. |
Beta Was this translation helpful? Give feedback.
-
AP certificate and Amazon certificate... Sorry Not getting it. Yes, I recommend upgrading to latest Oxalis version ASAP. |
Beta Was this translation helpful? Give feedback.
-
Sorry if I’m not the best to describe the issue. I have just gotten the oxalis AP code handed over to me without much documentation. Not so easy to find where to start. |
Beta Was this translation helpful? Give feedback.
-
What is the identifier you are sending to? Or it happens with all receivers? By the stacktrace it looks like an issue with receiving endpoint certificate. Try to check receiver number with https://peppol.helger.com/public/menuitem-tools-participant In general, UNAUTHORIZED OCSP response is returned when you validate a certificate against wrong OCSP server. This can happen if you have wrong certificate chain. Peppol lookup uses peppol-security https://github.com/OxalisCommunity/vefa-peppol/blob/master/peppol-security/src/main/resources/pki/ for corresponding mode (PROD/TEST) to build certificate chain. Maybe your deployment is corrupted, or by some reason it detected TEST mode but you send to PROD endpoints or vice versa or receiving endpoint published TEST certificate to PROD SMP... It is funny that google found by "Your signature was not authorized by the OCSP Server." only some Bolivian open source project https://gitlab.agetic.gob.bo/firmador_estatal/firmador-libreria/blob/develop/src/main/java/bo/gob/softwarelibre/firmadorestatal/firma/ocsp/OcspResponse.java#L44 |
Beta Was this translation helpful? Give feedback.
-
@dladlk Thanks for adding bit more details and pointer where it can go wrong. Regarding error message "Your signature was not authorized by the OCSP Server.", if you have narrow down search only within Oxalis repos, then you must have found it in https://github.com/OxalisCommunity/pkix-ocsp/blob/6820130842426917f6c4da02146c4444cf89e4aa/src/main/java/network/oxalis/pkix/ocsp/OcspResponse.java#L16 . Not to fully rely on google, when we have our own codebase supporting that :) |
Beta Was this translation helpful? Give feedback.
-
From the logs on our side all transactions to this AP failes. We send to lots of other AP without any issues. The 10. october everything was fine, on the 11. things started failing. Will check more tomorrow when I’m at work again |
Beta Was this translation helpful? Give feedback.
-
We are experiencing the same issues and it began 3.10.2024. Like @lOddifyr2, we haven't made any changes to our access point environment during this period. I have found this issue against just three accesspoints, but in the latest cases, there is now only one accesspoint left that we're experiencing these issues with. |
Beta Was this translation helpful? Give feedback.
-
Can you give an identifier of such receiver with which you experience the issue - so we can check what is specific at SMP response for it? |
Beta Was this translation helpful? Give feedback.
-
Last failed 0192:967354147 |
Beta Was this translation helpful? Give feedback.
-
As a data point: We're running vanilla Oxalis 6.7.0 and have not seen this error. We've successfully sent a number of messages to the receiver mentioned in the previous comment, both before and after 3.10.2024 |
Beta Was this translation helpful? Give feedback.
-
As far as I can see, it does not matter which Oxalis you use. OCSP lookup just gives a serial number of the certificate in question to URL found in intermediate certificate of OCSP server, in case of Peppol PROD - it is http://pki-ocsp.symauth.com I would suggest for Zirius to contact DigiCert asap and ask them to check why the above mentioned serial number is not authorized although you have it signed by them. |
Beta Was this translation helpful? Give feedback.
-
@dladlk When trying to send ehf to Zirius from Reknes or Uni Micro, which certificate is validated by OCSP? Sender certificate or Receiver AP certificate? What is the flow in oxalis, does it lookup recipient endpoint and then validates receiver peppol certificate using OCSP? |
Beta Was this translation helpful? Give feedback.
-
As an Access Point Provider, who earns money on this, you are expected to understand the standard flow of document exchange in Peppol. OCSP validation is not specific to Oxalis. But in short - ANY certificate should be checked for revocation - either via CRL or via OCSP. Look at the stacktrace in the beginning of this issue - OCSP fails on lookup result validation. Just write a simple code to validate the certificate of PNO00069 by yourself - and you will get the same error. Try to validate any other valid certificate - and you get no exception. Conclusion - something is wrong with that certificate at DigiCert. Finally, check DigiCert status page - https://status.digicert.com/incidents/5l59dym75xw1 : " We appreciate your patience and will provide updates as soon as the issue is resolved. I think it explains the case. Please don't forget to post here results of the request to DigiCert. |
Beta Was this translation helpful? Give feedback.
-
Converting this to discussion - Not an Oxalis issue |
Beta Was this translation helpful? Give feedback.
-
@lOddifyr2 @senikk We have contacted openPeppol and they suggested using a fallback routine on CRL revocation check if the OCSP fails, that fallback ensures that Sending APs can still transact with us. Mean while, they have approached Digicert with evidence of the OCSP error and will give a solution in near future. Can you make sure if CRL based certificate validation is used as a fall back, if OCSP validation fails in your oxalis version? |
Beta Was this translation helpful? Give feedback.
-
It stopped failing late friday 15.11.2024 |
Beta Was this translation helpful? Give feedback.
-
Hi!
On 2024/10/11 we started to have an issue with a receiving endpoint.
I have found that the error happens during lookup and the error message is as the title says: Your signature was not authorized by the OCSP Server. The last transaction that was successful was the day before (2024/10/10)
This accesspoint is the only one that throws this error, and I'm not sure how to or even where to start looking for the error. Does anyone have some tips on how to solve this?
We are running a bit old AP (4.1.0)
The stacktrace:
ERROR Client CorrelationId d48438eb-bf33-497e-867d-33f9392e3a99: Exception while sending message.
no.difi.oxalis.api.lang.OxalisTransmissionException: Your signature was not authorized by the OCSP Server.
at no.difi.oxalis.outbound.lookup.CachedLookupService.lookup(CachedLookupService.java:73)
at no.difi.oxalis.api.lookup.LookupService.lookup(LookupService.java:57)
at no.difi.oxalis.outbound.transmission.TransmissionRequestBuilder.build(TransmissionRequestBuilder.java:208)
at com.reknes.ap.bluegrass.oxalis.OxalisOutbound.send(OxalisOutbound.java:237)
at com.reknes.ap.bluegrass.Client.messageReceived(Client.java:173)
at com.reknes.ap.bluegrass.ovary.RabbitMqConsumer.fireMessage(RabbitMqConsumer.java:75)
at com.reknes.ap.bluegrass.ovary.RabbitMqConsumer.handleDelivery(RabbitMqConsumer.java:33)
at com.rabbitmq.client.impl.ConsumerDispatcher$5.run(ConsumerDispatcher.java:149)
at com.rabbitmq.client.impl.ConsumerWorkService$WorkPoolRunnable.run(ConsumerWorkService.java:104)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: no.difi.vefa.peppol.security.lang.PeppolSecurityException: Your signature was not authorized by the OCSP Server.
at no.difi.vefa.peppol.security.util.DifiCertificateValidator.validate(DifiCertificateValidator.java:64)
at no.difi.oxalis.commons.mode.OxalisCertificateValidator.perform(OxalisCertificateValidator.java:48)
at no.difi.oxalis.commons.mode.OxalisCertificateValidator.validate(OxalisCertificateValidator.java:33)
at no.difi.vefa.peppol.lookup.LookupClient.getEndpoint(LookupClient.java:105)
at no.difi.vefa.peppol.lookup.LookupClient.getEndpoint(LookupClient.java:115)
at no.difi.oxalis.outbound.lookup.CachedLookupService.load(CachedLookupService.java:79)
at no.difi.oxalis.outbound.lookup.CachedLookupService.load(CachedLookupService.java:46)
at com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3529)
at com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2278)
at com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2155)
at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2045)
at com.google.common.cache.LocalCache.get(LocalCache.java:3953)
at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:3976)
at com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4960)
at no.difi.oxalis.outbound.lookup.CachedLookupService.lookup(CachedLookupService.java:71)
Beta Was this translation helpful? Give feedback.
All reactions