Beiträge von h8tnluv

    Hallo,
    hab heute versucht ein Formular der SVA zu signieren, mit dem Ergebnis, dass der a.sign Client sang- und klanglos abstürzt. Ich denke, dass es mim Zusammenspiel mit dem SVA Portal hackt. Einloggen in das Portal funktioniert, und auch sonst konnte ich noch keine Probleme mit der lokalen BKU a.sign feststellen.


    Im Log ist folgendes ersichtlich:


    13:29:42 MESSAGE (12320): init HTTPClient CURL
    13:29:42 MESSAGE (12320): Add Certificate to SessionCache http://www.sozialversicherung.gv.at
    13:29:42 MESSAGE (12320): Check Certificate Validity /1.3.6.1.4.1.311.60.2.1.3=AT/businessCategory=Government Entity/serialNumber=R016Z6404/C=AT/ST=Wien/L=Wien/O=Hauptverband der oesterreichischen Sozialversicherungstraeger/OU=SVC Betrieb/CN=sozialversicherung.at
    13:29:42 MESSAGE (12320): VerifyCertificate
    13:29:42 MESSAGE (12320): load from VerifiedStore -> status:nok -> start verify
    13:29:42 DEBUG (12320): CertValidity:
    13:29:42 DEBUG (12320): ValidFrom: Mar 7 13:29:31 2016 GMT
    13:29:42 DEBUG (12320): ValidTo: Mar 7 13:39:00 2018 GMT
    13:29:42 DEBUG (12320): OCSP URLS:
    13:29:42 DEBUG (12320): http://ev.ocsp.quovadisglobal.com
    13:29:42 DEBUG (12320): using OCSP Network Function
    13:29:42 DEBUG (12320): HTTPClient::OcspRequest
    13:29:42 MESSAGE (12320): init HTTPClient CURL
    13:29:43 ERROR (12320): Cert nicht gefunden ski=41b1a8df
    13:29:43 ERROR (12320): error verify ocsp response
    13:29:43 ERROR (12320): ocsp: internal error

    13:29:43 DEBUG (12320): LDAP DP:
    13:29:43 DEBUG (12320): http://crl.quovadisglobal.com/qvevssl1.crl
    13:29:43 DEBUG (12320): using Uri Download Network Function
    13:29:43 MESSAGE (12320): URI download network function
    13:29:43 DEBUG (12320): uri is http(s) uri
    13:29:43 DEBUG (12320): HTTPClient::Get
    13:29:43 MESSAGE (12320): init HTTPClient CURL
    13:29:43 MESSAGE (12320): crl: verify ok
    13:29:43 MESSAGE (12320): Certificate Status OK
    13:29:43 DEBUG (12320): DomainCheck: sozialversicherung.at == http://www.sozialversicherung.gv.at
    13:29:43 DEBUG (12320): DomainCheck: http://www.sozialversicherung.at == http://www.sozialversicherung.gv.at
    13:29:43 DEBUG (12320): DomainCheck: http://www.sozialversicherung.gv.at == http://www.sozialversicherung.gv.at
    13:29:43 DEBUG (12320): DomainCheck: http://www.avsv.at == http://www.sozialversicherung.gv.at
    13:29:43 DEBUG (12320): DomainCheck: sso.sozialversicherung.at == http://www.sozialversicherung.gv.at
    13:29:43 DEBUG (12320): DomainCheck: analyse.sozialversicherung.at == http://www.sozialversicherung.gv.at
    13:29:43 DEBUG (12320): DomainCheck: sip.sozialversicherung.at == http://www.sozialversicherung.gv.at
    13:29:43 DEBUG (12320): DomainCheck: meinesv.at == http://www.sozialversicherung.gv.at
    13:29:43 DEBUG (12320): DomainCheck: http://www.meinesv.at == http://www.sozialversicherung.gv.at
    13:29:43 DEBUG (12320): DomainCheck: meinesozialversicherung.at == http://www.sozialversicherung.gv.at
    13:29:43 DEBUG (12320): DomainCheck: http://www.meinesozialversicherung.at == http://www.sozialversicherung.gv.at
    13:29:43 DEBUG (12320): DomainCheck: sozialversicherung.at == http://www.sozialversicherung.gv.at
    13:29:43 DEBUG (12320): .gv.at=true
    13:29:43 MESSAGE (12320): Zugriffsschutz: certifiedGovAgency
    13:29:43 MESSAGE (12320): IdentificationsURL:
    13:29:43 MESSAGE (12320): https://127.0.0.1:3496/https-security-layer-request
    13:29:43 MESSAGE (12320): _Zugriffsschutz()
    13:29:43 MESSAGE (12320): Zugriffsschutz (IdentificationRule): allow
    13:29:43 MESSAGE (12320): SecureViewer::Frame


    Hat noch jemand anderes dieses Problem?


    lg

    Hi,
    nachdem ich von der SV mit der neuen G3 beglückt wurde und mich durch deren HP Dschungel durchwühlte (offensichtlich bin ich nicht der einzige, der die Kommunikation der SV bescheiden findet), kam ich zur a-trust Seite auf der die ich die neue Karte aktivieren hätte können.


    Leider musste ich feststellen dass die bis dato funktionierende BKU Trustdesk basic nicht mehr mit der G3 funktioniert.


    Also versuchte ich (wieder einmal) den Umstieg auf die freie BKU MOCCA. Da ich in Besitz eines Gemalto GemPC Pinpad Readers bin, um die PINs über die Hardware einzugeben (was Keylogger Angriffe aushebelt) kontrollierte ich zuvor auch noch die Herstellerseiten bezüglich Treiberupdates, da hat sich seit 2009 aber nichts mehr getan.


    MOCCA v1.3.7 Installation verlief problemlos unter Win7 x64 und Java 1.6b22. Beim Test mit alter e-Card lief ich dann schnell in das klassische 4000 Fehler Problem.


    Nach einigem an Internet Recherche fand ich dann den Grund im MOCCA Logfile:


    [...]
    16:06:16,359 INFO smcc.STARCOSCard - STARCOS card found
    16:06:16,462 INFO smcc.STARCOSCard - e-card version=1.1 (<= G2)
    16:06:16,489 INFO smcc.STARCOSCard - File or application not found FID=[c0:02] SW=6a82.
    16:06:16,546 WARN smcc.STARCOSCard - Failed to execute command.
    javax.smartcardio.CardException: transmitControlCommand() failed
    at sun.security.smartcardio.CardImpl.transmitControlCommand(Unknown Source)
    at at.gv.egiz.smcc.reader.PinpadCardReader.VERIFY_PIN_START(PinpadCardReader.java:163)
    at at.gv.egiz.smcc.reader.PinpadCardReader.verifyPin(PinpadCardReader.java:267)
    at at.gv.egiz.smcc.reader.PinpadCardReader.verify(PinpadCardReader.java:602)
    at at.gv.egiz.smcc.STARCOSCard.verifyPIN(STARCOSCard.java:687)
    at at.gv.egiz.smcc.STARCOSCard.verifyPINLoop(STARCOSCard.java:648)
    at at.gv.egiz.smcc.STARCOSCard.getInfobox(STARCOSCard.java:259)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
    at java.lang.reflect.Method.invoke(Unknown Source)
    at at.gv.egiz.smcc.ExclSignatureCardProxy.invoke(ExclSignatureCardProxy.java:101)
    at $Proxy35.getInfobox(Unknown Source)
    at at.gv.egiz.bku.smccstal.InfoBoxReadRequestHandler.handleRequest(InfoBoxReadRequestHandler.java:57)
    at at.gv.egiz.bku.smccstal.AbstractSMCCSTAL.getResponse(AbstractSMCCSTAL.java:88)
    at at.gv.egiz.bku.smccstal.AbstractSMCCSTAL.handleRequest(AbstractSMCCSTAL.java:147)
    at at.gv.egiz.bku.local.stal.LocalBKUWorker.handleRequest(LocalBKUWorker.java:59)
    at at.gv.egiz.bku.local.stal.ExclusiveAccessSTAL.handleRequest(ExclusiveAccessSTAL.java:66)
    at at.gv.egiz.bku.slcommands.impl.STALHelper.transmitSTALRequest(STALHelper.java:101)
    at at.gv.egiz.bku.slcommands.impl.IdentityLinkInfoboxImpl.read(IdentityLinkInfoboxImpl.java:164)
    at at.gv.egiz.bku.slcommands.impl.InfoboxReadCommandImpl.execute(InfoboxReadCommandImpl.java:88)
    at at.gv.egiz.bku.binding.SLCommandInvokerImpl.invoke(SLCommandInvokerImpl.java:65)
    at at.gv.egiz.bku.binding.HTTPBindingProcessorImpl.processRequest(HTTPBindingProcessorImpl.java:310)
    at at.gv.egiz.bku.binding.HTTPBindingProcessorImpl.process(HTTPBindingProcessorImpl.java:691)
    at at.gv.egiz.bku.binding.AbstractBindingProcessor.run(AbstractBindingProcessor.java:124)
    at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
    at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
    at java.util.concurrent.FutureTask.run(Unknown Source)
    at at.gv.egiz.bku.binding.BindingProcessorFuture.run(BindingProcessorFuture.java:57)
    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
    at java.lang.Thread.run(Unknown Source)
    Caused by: sun.security.smartcardio.PCSCException: Unknown error 0x7a
    [...]


    Wie ich dem egovlabs JIRA entnehmen konnte, sind Probleme mit dem Gemalto bekannt (Issue 757) und auch schon für MOCCA 1.4.0 gescoped, wann kann man denn mit dem Release rechnen?
    Gibt es eine andere BKU die mit dem Gemalto einwandfrei funktioniert?


    Btw, gibt es die Firma IT-Solution eigentlich noch, da deren CMS auf der HP einen grandiosen Windows Fehler liefert...


    Bin für jeden Tipp dankbar.