radiac / caman Goto Github PK

I plan to implement this by adding an optional argument to init to specify the caman dir for the root CA, eg ./caman init /path/to/root_ca/.

Caman can then use the root CA to sign the intermediate CA and generate a chain file, at which point the intermediate CA would be a self-contained caman dir with its own config, and all other syntax would remain the same.

I have no pressing need for this, so I'll update this issue when I start working on it. In the meantime, comment here if this is something you're interested in, and of course patches would be most welcome.

I'm currently using something based upon CA-baka, and am looking for a new implementation before my existing certificates all start to expire.

One thing your project is missing is support for SAN, which would allow me to generate a certificate for multiple hostnames. For example right now I do this kind of thing:

  ./CA-baka --workdir CA/ --newserver dhcp webmaster\@dhcp.io --altnames DNS:dhcp.io --altnames DNS:www.dhcp.io --altnames DNS:pxe.io --altnames DNS:www.pxe.io

That gives me a certificate for the names:

• pxe.io
• www.pxe.io
• dhcp.io
• www.dhcp.io

Adding support for this is a bit fiddly because you essentially have to write a small openssl configuration-file with a snippet for each name:

DNS=foo.example.com
DNS=bar.example.com
DNS=www.example.com

Is there a way to renew an intermediate ca?

For example, Chrome 61, the current Canary version, will fail to connect with ERR_CERT_COMMON_NAME_INVALID, even though the common name matches. Therefore it is now necessary to include Subject Alternative Name even when the certificate only specifies a single domain name.

A certificate produced using caman new only-one.domain.he.re does not include any Subject Alternative Names, and will be rejected. A workaround is to specify the same domain name twice, caman new my.domain.na.me my.domain.na.me, and this produces a working certificate, but it actually produces two copies of the domain name in the SAN field so it's not ideal.

To compensate for the current handling of certificates, caman should simply always set the Subject Alternative Name field, even when only one domain name is required.

I've just found this on GitHub - thank you!
This is more a feature request - could you add creating and managing client certificates as well?

Cheers,

Hello,

I've followed the procedure to set up a root-CA and an intermediate-CA. Actually, the intermediate-CA was successfully deployed as far as I can see.
However, once I tried to sign a new certificate on the intermediate, I received following error message:
[...]
Signing the certificate...
Using configuration from /usr/local/bin/caman-int/ca/caconfig.cnf
Unable to load CA private key
140119815997080:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:evp_enc.c:592:
140119815997080:error:0906A065:PEM routines:PEM_do_header:bad_decrypt:pem_lib.c:482:

I did start ./caman sign my.host.name as root (via sudo) and I've checked the private key entry in caconfig.cnf and the permissions and content of the private key file itself. All of this looks good.

I made another approach signing a new host certificate from the root-CA which worked out as expected.

Any idea what I'm missing?

Thanks,
Thomas

I'm not new to windows, nor Git or Python,

I've cloned the REPO, configured the CNF files, but I'm confused about step 4:

cd caman
./caman init

how do I initialize in windows?

I've tried with python/pip, and some other tools, but I guess I'm missing something?

Thanks,

My certificates stopped working after updating my phone to iOS 13.

After some googling I found this page:

https://support.apple.com/en-us/HT210176

So - they will likely also fail in OSX 10.15 when it arrives later this month.

Note that this only affects the host cert's - my CA cert is still working fine.

I had to make two changes to my ca/host.cnf (and to the config.cnf's generated from it)

1. Change default_days to under 825 - anything longer gets rejected
2. Update the [ v3_req ] block

Current:

[ v3_req ]
basicConstraints        = CA:FALSE
keyUsage                = nonRepudiation, digitalSignature, keyEncipherment
<<ALT_HOSTNAMES>>

Updated:

[ v3_req ]
basicConstraints        = CA:FALSE
keyUsage                = nonRepudiation, digitalSignature, keyEncipherment
extendedKeyUsage        = serverAuth, clientAuth
<<ALT_HOSTNAMES>>

Not sure what you may want to change - the number of days you might want to leave and have a README comment ?

I think the adding of the extendedKeyUsage is OK for everyone - I can see for example my LetsEncrypt certificates all have that.

After configuration and when running caman init, I get:

Generating CA private key...
Enter CA password for /user/work/it/caman: 
Generating RSA private key, 4096 bit long modulus
...............................................................................................................................................................++++
.++++
e is 65537 (0x010001)
Signing CA public certificate...
Generating CRL...
Using configuration from /user/work/it/caman/ca/caconfig.cnf
Can't open ./ca/index.txt.attr for reading, No such file or directory
140151468554048:error:02001002:system library:fopen::crypto/bio/bss_file.c:74:fopen('./ca/index.txt.attr','r')
140151468554048:error:2006D080:BIO routines:BIO_new_file:no such file:crypto/bio/bss_file.c:81:
Certificate authority created

while it still worked, this could be worked around by creating the ca/index.txt.attr file manually before, see also this stackoverflow post

well, i adjust to add the config option for the openssl binary path, when there are multiple versions on the server , and sometime i want to use the specified version but the $PATH , /bin/openssl or /usr/bin/openssl or anything export path , are not allowed to be changed.

thanks!