Activity for Tomas Gustavsson
-
Tomas Gustavsson posted a comment on discussion Open Discussion
There are some similar posts in the Discussion session. If you can post there it's good to keep it together. https://github.com/Keyfactor/ejbca-ce/discussions
-
You should contact keyfactor support, they should be able to help you with that quickly.
-
EJBCA discussions have moved here: https://github.com/Keyfactor/ejbca-ce/discussions
-
Hi Pham, SignServer discussions moved to https://github.com/Keyfactor/signserver-ce/discussions. My guess is that you have not added your wildfly user to the "hsmusers" group. This is needed.
-
You can find the new discussion forum here: https://github.com/Keyfactor/ejbca-ce/discussions (linked from ejbca.org as well)
-
Discussions have moved to https://github.com/Keyfactor/ejbca-ce/discussions Please state which version of EJBCA you are using when posting there and explain what commands you use.
-
Hi, The EJBCA discussion channel has officially moved here: https://github.com/Keyfactor/ejbca-ce/discussions For Bitnami VM you need to askBitnami support. We have no insight in how their VM works, they create that themselves You can find the official EJBCA Container on DockerHub, https://hub.docker.com/r/keyfactor/ejbca-ce
-
Follow on GitHub: https://github.com/Keyfactor/ejbca-ce/discussions/528
-
Please post here: https://github.com/Keyfactor/ejbca-ce/discussions
-
Closing this thread, moved to GitHub.
-
Dev: Please create a new issue in GitHub. https://github.com/Keyfactor/ejbca-ce/discussions Deleting these.
-
Hi Alexandre, can you move this topic to GitHub? https://github.com/Keyfactor/ejbca-ce/discussions
-
Hi Dev, this is not realated to the topic of this issue. Please post questions under a new thread, on GitHub. https://github.com/Keyfactor/ejbca-ce/discussions
-
You can see this issue, and continue the discussion in that channel. https://github.com/Keyfactor/ejbca-ce/issues/473
-
Hi, Can you post this to the GitHub discussions. With some more details such as what version of EJBCA you are using, what version of application server, version of Java, and such. https://github.com/Keyfactor/ejbca-ce/discussions
-
Hi, Please continue the discussion here: https://github.com/Keyfactor/ejbca-ce/discussions There are many docker related discussions there.
-
Please continue the discussion here: https://github.com/Keyfactor/ejbca-ce/discussions There are many docker and env discussions there.
-
Thanks for the report. This will be fixed and a new zip file uploaded. Thanks again!
-
Yes, using a Galera cluster is extremely common. It's a base component of the Keyfactor HW and SW Appliances. There are hundreds of Galera cluster installations out there. There should be logs somewhere. A 404 doesn't occur unless yo use the wrong URL, or something failed to deploy, and failed deployments will be visible in the log.
-
No
-
Then you have to dig into Java SSL debugging, which can be complicated. But you can get it to debug every decision it makes and everything that happens. But indeed RSASSA-PSS is tricky in the Java PKCS#11 provider, it's not commonly used I believe, hence issues.
-
Your JDK was already higher than 272 wasn't it. You don't have to downgrade that will not help. Are you using 4096 bit keys? You only have to restart JBoss/WildFly.
-
RSASSA-PSS support in the Java PKCS#11 provider has been shaky. See here: https://doc.primekey.com/ejbca/ejbca-integration/hardware-security-modules-hsm#HardwareSecurityModules(HSM)-Using_SHA256WithRSAandMGF1_(RSASSA-PSS)UsingSHA256WithRSAandMGF1(RSASSA-PSS) An upgrade of EJBCA might help for some things, like moving to Java 11.. I know I have tested this before. But indeed, as the link says, it only worked/works with 4096 bit RSA keys. Don't know if they have fixed that bug, if they have I suspect...
-
This does not sound relevant for this old thread, from 2016. See here for newer discussions. https://github.com/Keyfactor/ejbca-ce/discussions
-
There are lots of great tutorial videos on the KeyfactorCommunity YouTube channel on how to use the container. https://www.youtube.com/@KeyfactorCommunity
-
I suggest that you try the container, and then you can look at how that is configured, and if you absolutely need to build from source you can replicate that configuration. https://hub.docker.com/r/keyfactor/ejbca-ce
-
Can you post the question to the new forum here: https://github.com/Keyfactor/signserver-ce/discussions
-
Can you post the question to the new discussion forum on GitHub. https://github.com/Keyfactor/ejbca-ce/discussions Cheers, TOmas
-
I have non repudiation in my superadmin certificate, it's an old one, and it works fine. So that should not be the issue. I see your URL you put above is port 443, so do you have a proxy in front of wildfly (which typically runs on port 8443). Try to go against wildfly directly https on port 8443.
-
Thanks. I noted a ticket the use of EC for the initial superadmin with the ENDUSER certificate profile.
-
Please ask questions here from now: https://github.com/Keyfactor/ejbca-ce/discussions
-
Please find the new forum here: https://github.com/Keyfactor/ejbca-ce/discussions Not sure about this, might be that the server rejects your client certificate as it contains some invalid key usage. Key Enciperment is not a valid key usage for EC keys. You can see browser requirements in CA/B Forum Baseline Requirements. For EC keys you should only have Digital Signature for a web authentication certificate. Also you should limit extended key usage to Client Authentication, and not use the same certificate...
-
Try to set httpsserver.hostname in conf/web.properties
-
When your Root CA is an External CA, you should select signed by "External" when creating the Sub CA in EJBCA. See here: https://doc.primekey.com/ejbca/ejbca-operations/ejbca-operations-guide/ca-operations-guide/managing-cas/creating-an-issuing-ca-signed-by-an-external-root
-
This is duplicate issue. https://github.com/Keyfactor/signserver-ce/discussions/53 Only need to post in one place.
-
Hi PeerConnectors is an Enterprise feature. You will get much better responses by contacting Keyfactor support. https://support.keyfactor.com/ Cheers, Tomas
-
I would just upgrade you old 7.4 to the latest version. It might be an issue with the RA Web that was just fixed. You should upgrade anyhow to make sure you don't have any security issues. You can always check the changelog summary to all the things that have changed. https://doc.primekey.com/ejbca/ejbca-release-information/ejbca-release-notes/ejbca-change-log-summary
-
Please see the new forum here: https://github.com/Keyfactor/ejbca-ce/discussions 60 means "archived", this state is set when CRLs are generated. Perhaps you don't generate CRLs regularly in the old installation?
-
Key files in softHSM is (by default) stored in /var/lib/softhsm. By default they are accessible by root and the softhsm user group. Anyone who want to use the slots/keys need to be parts of the softhsm group. In short, add your wildfly user to the softhsm group in the OS.
-
Find your old end entity (probably "superadmin"?) and reset status on this entity to "New" and set a new password. This ensures that you get a certificate with the same Subject DN. Otherwise you will need to modify roles to give your new entity access to the system. You can find lots of documentation on-line, not for version 3.9.7 thought. But that documentation should be in your system under the "Documentation" link. https://doc.primekey.com/ejbca/ejbca-operations/ejbca-ca-concept-guide/roles-and-access-rules...
-
You can use the command line interface to renew, It should say something about it in the documentation, with commands. Otherwise you can always set the clock back on the machine(s) and get into the UI. There is a new place for discussions is here: https://github.com/Keyfactor/ejbca-ce/discussions PS: Impressive to manage to run such an old version, including hardware, OS, java, and all. Cheers, Tomas
-
You can find the new place for discussions here: https://github.com/Keyfactor/ejbca-ce/discussions I would recommend that you look at how bin/ejbca.sh, the ejbca CLI, does this. https://github.com/Keyfactor/ejbca-ce/tree/main/modules/ejbca-ejb-cli Assuming that the CLI works, you should be able to just do the same thing. Modify some CLI classes to start with.
-
Suggest to move discussion to here: https://github.com/Keyfactor/ejbca-ce/discussions Much more of the log is needed, and runinstall output. Perhaps your CLI can't contact the server.
-
It works for me In the field for the url you enter something like "uri=https://id.gov.se/" PS: the new home for EJBCA discussions are https://github.com/Keyfactor/ejbca-ce/discussions
-
Peer Connectors in an Enterprise feature. https://doc.primekey.com/ejbca/ejbca-operations/ejbca-ca-concept-guide/peer-systems If you use this you must be running EJBCA Enterprise, in which case your organization should have an SLA. If you need help setting up your account you can always email support(at)keyfactor.com. Cheers, Tomas
-
Hi, Since Peers is an Enterprise feature, please contact support to get timely help. This Community channel is for no-SLA community help. https://support.keyfactor.com/hc/en-us Cheers, Tomas
-
You don't have to delete anything. ou have configured "ca.tokentype : org.cesecore.keys.token.PKCS11CryptoToken" in conf/install.properties. Simply change back those configurations to the defaults.
-
Hi, If you are using Enterprise, please contact support, to ensure you get help fast. This Community channel does not have an SLA and have no guarantees for timely assistance. https://support.keyfactor.com/hc/en-us Regards, Tomas
-
(The main discussion forum has moved to https://github.com/Keyfactor/ejbca-ce/discussions) Since you are using an HSM for the initial install, the most likely issue is HSM related. You should try first to make a standard installation (with soft crypto token), and in that installation create a crypto token for your HSM. That will ensure that you HSM connection and configuration works first.
-
See GitHub discussions for more recent discussions: https://github.com/Keyfactor/ejbca-ce/discussions For constants you can see here: https://github.com/Keyfactor/ejbca-ce/blob/main/modules/cesecore-common/src/org/cesecore/certificates/certificate/CertificateConstants.java here: https://github.com/Keyfactor/ejbca-ce/blob/main/modules/cesecore-common/src/org/cesecore/certificates/ca/CAConstants.java and for example here: https://github.com/Keyfactor/ejbca-ce/blob/main/modules/cesecore-common/src/...
-
This sounds like a different topic. You can move the discussion to GitHub, where there is a question like this, with lots of info in it, that you can start to look at. https://github.com/Keyfactor/ejbca-ce/discussions
-
And yes, it definitely can have to do with java version. Java is changing a lot in sunp11 between releases and things are starting to shake up, especially related to RSA: Getting interoperability between sunP11 and different HSMs is starting to get really hard (as it comes to RSA).
-
There is a setting in EJBCA that can be set in conf/cesecore.properties called. pkcs11.disableHashingSignMechanisms By setting this to false that specific CKM_RSA_SHA256 etc mechanisms will be used instead. This causes the full objects-to-be-signed to be sent to the HSM though, which typically is a lot slower. I think we just need to stop using RSA in FIPS configurations, RSA is starting to be really hard to use efficiently. It's time to seriously consider retiring RSA.
-
What version of Java are you using?
-
You will see in server.log when the driver jar is deployed, if you copy it to the deployment directory. My huess is that your myswl jar fie has not been deployed and available in WildFly. The server.log will also show the name that WildFly uses.
-
Which guide did you follow? The linked instruction says to copy the driver jar file into standalone/deployments, with a generic name without the version number. You write above that you copied it to /usr/local/wildfly/modules/system/layers/base/com/mysql/main. Specific link with commands for the jdbc driver: https://doc.primekey.com/ejbca/ejbca-installation/application-servers/wildfly-22-jboss-eap-7-4#WildFly22/JBossEAP7.4-AddDatabaseDriver
-
I would suggest that you mimic the configuration that is documented here: https://doc.primekey.com/ejbca/ejbca-installation/application-servers/wildfly-22-jboss-eap-7-4 If you use mysql instead of mariadb, it should be identical. You should not need a module.xml file. The naming things of these commands can be tricky. But the path in the documentation works well.
-
The latest version is always recommended. Look at ejbca.org to find the documentation and download links (and also link to new discussion forum on GitHub).
-
"Unable to build certificate chain for OCSP signing certificate with Subject DN 'CN=OCSP_CA_KeyBinding,OU=BRN xxx,O=USER CERT,C=HK'. CA with Subject DN 'CN=ROOT CA CERT (TRIAL),OU=BRN xxx,O=TESTING COMP,C=HK' is missing in the database." The Root CA does not seem to be imported?
-
The official installation guide is as https://www.ejbca.org/, always check there first. Most guides on the internet written by other people are not maintained over time, and are more static snapshots in time. The above looks like a connection issue, like it is not possible to connec to to 192.168.233.100 from the machine you run the command on. That is a network issue.
-
Hi, EJBCA uses whatever JPA version the application server supports, the highest really. EJBCA also just uses the Hibernate jars that are bundled with WildFly. As long as you can read the database tables, you should be able to use any JPA version that is supproted by your WildFly version. PS: I'd be glad to continue the discussion on GitHub discussions. https://github.com/Keyfactor/ejbca-ce/discussions Regards, Tomas
-
Check what Java version you are using and if that is supported on new and old OS. The java version is more important than the OS itself. You definitely need to upgrade EJBCA, you should not run an extremely old version with known vulnerabilities. All your different routes are possible...but check java version first.
-
You can find the pre-requisites here: https://doc.primekey.com/ejbca/ejbca-installation/installation-prerequisites Officially 7.11 is Java 11, but we're working towards Java 17. It can work with Java 17, but not as well tested. I'd go with 11. EJBCA 8.0 will be official on Java 17.
-
It does not. The latest version of EJBCA is 7.11. Webservice is a protocol over the network though, and does not rely on java version itself. You can run different Java version for EJBCA and your client. But you should upgrade EJBCA. See here: https://github.com/Keyfactor/ejbca-ce and here: https://www.ejbca.org/
-
This version of EJBCA is 6 years old. Just use the latest release and installation instructions. https://doc.primekey.com/
-
Continuing at GitHub.
-
Not that I know of. What do you mean with does not allow? If it works in clientToolBox it usually means it works in EJBCA. You can continue the discussion at GitHub: https://github.com/Keyfactor/ejbca-ce/discussions
-
If you an post the question on GitHub that would be good. This is the active support channel. https://github.com/Keyfactor/ejbca-ce/discussions
-
You can hope. No guarantees, as I can not understand what your issue is. Did you try enabling debug log and see what is logged is you remove only "CA issuer Default URI" and press save? Can you save any values on the CA, or do the yellow fields prevent saving anything? I.e. values in those fields do no harm, but if it prevents you editing anything else on the CA it would be a problem. What browser are you using btw? I'm using Firefox.
-
Thanks. Since I tried on EJBCA 7.10 (and later), the first thing I can recommend is to upgrade in a test environment.
-
Just go there next time. I just tested again on an on-kine instance I have. First I set CA issuer Default URI to "http://abc.se/" and CMP RA Authentication Secret to qwerty. Then I edited the CA again. CMP RA Authentication Secret is a bit special, since it is a secret the value is not reflected back I could remove CA issuer Default URI without problem, and it's blank after saving. Saving the CA without value in CMP RA Authentication Secret removed it from the database. Neither of these fields does...
-
I run my database that is many years old. I could not reproduce this. And have not heard about it before, so it doesn't seem to be anything that generally affects updates. You should be able to edit these values. CA Issuer Default URI, should be a URL. Authentication secret is a normal string. Are you running any custom code? See here for the latest updates: https://github.com/Keyfactor/ejbca-ce/discussions
-
Here you are: https://github.com/Keyfactor/ejbca-ce/blob/main/modules/cesecore-common/src/org/cesecore/certificates/certificate/CertificateConstants.java
-
Oh, this was in the outbox, was supposed to be posted days ago. CERT_INACTIVE = 10 CERT_ACTIVE = 20 CERT_NOTIFIEDABOUTEXPIRATION = 21 CERT_REVOKED = 40 CERT_ARCHIVED = 60 You can follow/continue the discussion on GitHub. https://github.com/Keyfactor/ejbca-ce/discussions
-
Not correct. The CLI does not access the database directly. It access EJBCA APIs, and uses a username/password authentication for that. You have a properties file in the CLI with default username/password to use by the client, and there are also parameters to the CLI to enter username/password. There is an end entity in EJBCA, default "ejbca" which is used for this. PS: the new main forum for discussions is now: https://github.com/Keyfactor/ejbca-ce/discussions
-
What version of EJBCA is it? There is a database there, but it doesn't have to be named ejbca, it depends on what database name you created. Check your JBoss/WildFly configuration, in standalone.sh. The CLI error is likely due to some configuration done in EJBCA before superadmin expired. Either the CLI user (by default 'ejbca') was modified, your CLI was configured to use another user, or the role where the CLI user is added was modified. Everything of this is of course fixable, but depending on...
-
You can edit the database directly. You an also edit the end entity with superadmin (with access to both profiles/CAs). But I don't think you can changed user ee profile in 6.11?, you can in 7.11. You can also use the WS API, clientToolBox to edit the user. Many ways, no serious consequences to edit an end entity.
-
I can not reproduce that. If I try to add an end entity with the same username, I get an error message as you can see in the screenshot. If the end entity profile I have access to only have "one" as allowed certificate profile and CA, it's the only options available. Your version is very old though. If you upgrade you will see many improvements.
-
I can not reproduce that. If I try to add an end entity with the same username, I get an error message as you can see in the screenshot. If the end entity profile I have access to only have "one" as allowed certificate profile and CA, it's the only options available. Your version is very old though. If you upgrade you will see many improvements.
-
How do you add/edit the end entity? SOAP API?
-
You are getting the concepts wrong. A user does not belong to a profile. A user uses a profile. You can edit the user to switch from profile 1 to profile 2. You are not adding a new user, you are editing the existing user. As username is primary key, there can only exist one user with a specific username. But if you have the privileges to edit users, you can edit it and issue multiple certificates from different profiles and different CAs to this user. It is not uncommon that a single user have multiple...
-
It sounds like an expected behavior. You are editing the existing end entity. Don't know how you are doing this, but most API calls are designed like this, add end entity if it doesn't exist, edit end entity if it exists.
-
I would be glad to continue the discussion at GitHub. https://github.com/Keyfactor/ejbca-ce/discussions In short it has to do with network security and segmentation and not with the security of mTLS itself. A CA is one of the most central security components of an infrastructure, and it is often desired to have it as isolated as possible on the network. Not enabling any incoming connections to the CA is one piece of protection that minimizes the risk that any network component, such as a network...
-
Did you find this information about and deploy-datasource in HOWTO-database.txt? There is no such command since a long time. I will update that text file for the next release removing that. Just follow the installation guide. https://doc.primekey.com/ejbca/ejbca-installation/application-servers In database.properties you only need to configure database.name as it says in the database.properties.sample file. The other settings can be ignored (unless for the database CLI as it also mentions, but that...
-
Did you re-create the CA or something? Sounds like the superadmin certificate was issued by another key or something like that. - delete superadmin from the web browser - re-generate the superadmin p12 keystore from EJBCA (you can use the CLI) - re-install the superadmin.p12 into the browser
-
There is no errors at all in the log snippet you paste there. Are you sure it's all that WildFly prints? I see that you enabled DEBUG logging for EJBCA.. Did you configure EjbcaDS in WildFly? Typically that should be logged by WildFly during startup.
-
The cert looks ok. What browser are you using? Is the Admin CA certificate installed in the trust store? On the other hand, searching for the error code says that it's used by Chrome when it does not accept the server certificate. https://cheapsslsecurity.com/blog/how-to-fix-err-bad-ssl-client-auth-cert-error-chrome/ The error is between the server (wildfly) and the browser, and not by EJBCA itself, so it's debugging what in the cert Chrome does not like. Some suggestions: - Try the fixes in the...
-
This is a TLS connection error, something that should be due to the technical configuration of your admin client certificate. Did you configure the certificate profile in a custom way? Typical things that can cause this are: - invalid key usage for the certificate, possbly related to the key type you use - extended key usage not being Client Authentication - Using DSA instead of RSA or EC is something we've seen a couple of times If you want you can post your admin certificate, or a screen shot of...
-
What is the TSU? Do you have a reference for that? Or do you mean https://www.ietf.org/rfc/rfc3161.txt? Cheers, Tomas
-
EJBCA have multiple systems for logging and you can configure them in many ways. https://doc.primekey.com/ejbca/ejbca-operations/ejbca-ca-concept-guide/logging The logging done through WildFly (Log4jLogDevice) can be disable if you have access to reconfigure the application server. This requires access to the server though, so the server is then breached which would be very bad in any case. The second (configurable) logging is logging to the database, which does not go through the WildFly logging...
-
First, you should use the latest version of EJBCA, which is now 7.10.0.1. Yes EJBCA Community works both as a CA and VA. Cheers, Tomas
-
the term "security world" is not a term used in EJBCA. Security world is typically a term associated with nCipher/Entrust nShield HSMs. https://doc.primekey.com/ejbca/ejbca-integration/hardware-security-modules-hsm/ncipher-nshield-nethsm
-
This time is there to allow some time difference between client and CA computers, so the client will not consider the issued certificate invalid if it's clock is off by for example one minute. You can control this with the setting "Validity Offset" in certificate profiles.
-
Hi, When using a MarieDB Glera cluster with say three nodes, each EJBCA node typically connects to it's "own" MariaDB node, making the EJBCA+MariaDB "one package" for each node. There is nothing preventing you from running a Galera cluster of your own, with a VIP in-front of course, that is also a valid deployment model (but not how it works in the Appliance).
-
There is no RFC that specifies the minimum value. It is because EJBCA uses random serial numbers (as required by many current standards), it does not make sense with too small serial numbers, the number of certificates possible to issue will be too small.
-
Thanks, great to know. We'll try to figure out why that happens sometimes, not for all.
-
It should not ask for password, but only use client cert authentication normally. That WildFly did you use? I've seen it myself when trying WF24 I think, but didn't figure out why.
-
Ok, I can not reproduce it in the current working version, so assuming it will not pear in the next release.
-
So was it related to the HSM or not? Did it work on 7.9 after removing the crypto token using the CLI?
-
The stack trace does not seem related to crypto tokens, but configuration in general. Would a browser/server restart solve it?
1 >